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Abstract. A feature-oriented product line is a family of programs that share a 
common set of features. A feature implements a stakeholder's requirement, rep- 
resents a design decision and configuration option and, when added to a program, 
involves the introduction of new structures, such as classes and methods, and the 
refinement of existing ones, such as extending methods. With feature-oriented 
decomposition, programs can be generated, solely on the basis of a user's selec- 
tion of features, by the composition of the corresponding feature code. A key 
challenge of feature-oriented product line engineering is how to guarantee the 
correctness of an entire feature-oriented product line, i.e., of all of the member 
programs generated from different combinations of features. As the number of 
valid feature combinations grows progressively with the number of features, it 
is not feasible to check all individual programs. The only feasible approach is 
to have a type system check the entire code base of the feature-oriented product 
line. We have developed such a type system on the basis of a formal model of a 
feature-oriented Java-like language. We demonstrate that the type system ensures 
that every valid program of a feature-oriented product line is well-typed and that 
the type system is complete. 



1 Introduction 

Feature-oriented programming (FOP) aims at the modularization of programs in terms 
of features 0551131 . A feature implements a stakeholder's requirement and is typically 
an increment in program functionality 0551131 . Contemporary feature-oriented pro- 
gramming languages and tools such as AHEAD fl3|, Xak |2|, CaesarJ |48|, Class- 
box/J [141 , FeatureHouse [91, and FeatureC-H- |10| provide a variety of mechanisms 
that support the specification, modularization, and composition of features. A key idea 
is that a feature is implemented by a distinct code unit, called a. feature module. When 
added to a base program, it introduces new structures, such as classes and methods, and 
refines existing ones, such as extending methods 04311 II . A program that is decomposed 
into features is called henceforth a. feature-oriented program^ 

' Typically, feature-oriented decomposition is orthogonal to class-based or functional 
decomposition 163 14916 II . A multitude of modularization and composition mecha- 
nisms I17I26I24I45I46I56I65I have been developed in order to allow programmers to decom- 
pose a program along multiple dimensions [63 '|. Feature-oriented languages and tools provide 
a significant subset of these mechanisms LI IJ . 



Beside the decomposition of programs into features, the concept of a feature is 
useful for distinguishing different, related programs thus forming a software product 
line 113512 11. Typically, programs of a common domain share a set of features but also 
differ in other features. For example, suppose an email client for mobile devices that 
supports the protocols IMAP and POP3 and another client that supports POP3, MIME, 
and SSL encryption. With a decomposition of the two programs into the features IMAP, 
POP3, MIME, and SSL, both programs can share the code of the feature POP3. Since 
mobile devices have only limited resources, unnecessary features should be removed. 

With feature-oriented decomposition, programs can be generated solely on the ba- 
sis of a user's selection of features by the composition of the corresponding feature 
modules. Of course, not all combinations of features are legal and result in correct 
programs |12|. A feature model describes which features can be composed in which 
combinations, i.e., which programs are valid 1135121 1. It consists of an (ordered) set 
of features and a set of constraints on feature combinations II21I12L For example, our 
email client may have different rendering engines for HTML text, e.g., the Mozilla en- 
gine or the Safari engine, but only one at a time. A set of feature modules along wit a 
feature model is called s. feature-oriented product line 012 1. 

An important question is how the correctness of feature-oriented programs, in par- 
ticular, and product lines, in general, can be guaranteed. A first problem is that con- 
temporary feature-oriented languages and tools usually involve a code generation step 
during composition in which the code is transformed into a lower-level representation. 
In previous work, we have addressed this problem by modeling feature-oriented mech- 
anisms directly in the formal syntax and semantics of a core language, called Feature 
Featherweight Java (FFJ). The type system of FFJ ensures that the composition of 
feature modules is type-safe |8|. 

In this paper, we address a second problem: How can the correctness of an entire 
feature-oriented product line be guaranteed? A naive approach would be to type-check 
all valid programs of a product line using a type checker like the one of FFJ (E] . How- 
ever, this approach does not scale; already for 34 implemented optional features, a vari- 
ant can be generated for every person on the planet. Noticing this problem, Czarnecki 
and Pietroszek f22l and Thaker et al. f64\ suggested the development of a type sys- 
tem that checks the entire code base of the feature-oriented product line, instead of all 
individual feature-oriented programs. In this scenario, a type checker must analyze all 
feature modules of a product line on the basis of the feature model. We will show that, 
with this information, the type checker can ensure that every valid program variant that 
can be generated is type-safe. Specifically, we make the following contributions: 

- We provide a condensed version of FFJ, which is in many respects more elegant 
and concise than its predecessor ||8]. 

- We develop a formal type system that uses information about features and con- 
straints on feature combinations in order to type-check a product line without gen- 
erating every program. 

- We prove correctness by proving that every program generated from a well-formed 
product line is well-formed, as long as the feature selection satisfies the constraints 
of the product Une. Furthermore, we prove completeness by proving that the well- 
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typedness of all programs of a product line guarantees that the product line is well- 
typed as a whole. 

- We offer an implementation of FFJ, including the proposed type system, which can 
be downloaded for evaluation and for experiments with further feature-oriented 
language and typing mechanisms. 

Or work differs in many respects from previous and related work (see Section |5] 
for a comprehensive discussion). Most notably, Thaker et al. have implemented a type 
system for feature-oriented product lines and conducted several case studies [64|. We 
take their work further with a formalization and a correctness and completeness proof. 

Furthermore, our work differs in many respects from previous work on modeling 
and type-checking feature-oriented and related programming mechanisms. Most no- 
tably, we model the feature-related mechanisms directly in FFJ's syntax and semantics, 
without any transformation to a lower-level representation, and we stay very close to 
the syntax of contemporary feature-oriented languages and tools (see Section |5]l. We 
begin with a brief introduction to FFJ. 

2 Feature-Oriented Programs in FFJ 

In this section, we introduce the language FFJ. Originally, FFJ was designed for feature- 
oriented programs 18171 . We extend FFJ in Section|3]to support feature-oriented product 
lines, i.e., to support the representation of multiple alternative program variants at a 
time. 

2.1 An Overview of FFJ 

FFJ is a Ughtweight feature-oriented language that has been inspired by Featherweight 
Java (FJ) Il32l . As with FJ, we have aimed at minimality in the design of FFJ. FFJ 
provides basic constructs like classes, fields, methods, and inheritance and only a few 
new constructs capturing the core mechanisms of feature-oriented programming. But, 
so far, FFJ's type system has not supported the development of feature-oriented product 
lines. That is, the feature modules written in FFJ are interpreted as a single program. 
We will change this in Section [3] 

An FFJ program consists of a set of classes and refinements. A refinement extends a 
class that has been introduced previously. Each class and refinement is associated with 
a feature. We say that a feature introduces a class or applies a refinement to a class. 
Technically, the mapping between classes/refinements and the features they belong to 
can be established in different ways, e.g., by extending the language with modules rep- 
resenting features |48 14 23 1 or by grouping classes and refinements that belong to a 
feature in packages or directories M13I10L 

Like in FJ, each class declares a superclass, which may be the class Object. Refine- 
ments are defined using the keyword refines. The semantics of a refinement applied to 
a class is that the refinement's members are added to and merged with the member of 
the refined class. This way, a refinement can add new fields and methods to the class 
and override existing methods (declared by overrides). 
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On the left side in Figure [T] we show an excerpt of the code of a basic email cUent, 
called EmailClient, (top) and a feature, called SSL, (bottom) in FFJ. The feature 
SSL adds the class SSL (Lines 7-10) to the email client's code base and refines the 
class Trans in order to encrypt outgoing messages (Lines 11-15). To this effect, the 
refinement of Trans adds a new field key (Line 12) and overrides the method send of 
class Trans (Lines 13-15). 

Feature EmailClient 

1 class Msg extends Object { 

2 String serialize() { ... } 

3 } 

4 class Trans extends Object { 

5 Bool send(Msg m) { ... } 

6 } 

Feature SSL 

7 Class SSL extends Object { 

8 Trans trans; 

9 Bool send(Msg m) { ... ) 

10 } 

1 1 refines class Trans { 

12 Key key; 

13 overrides Bool send(Msg m) { 

14 return new SSL(thls).send(m); 

15 ) 

16 } 

Fig. 1. A feature-oriented email client supporting SSL encryption. 

Typically, a programmer applies multiple refinements to a class by composing a 
sequence of features. This is called a refinement chain. A refinement that is applied 
immediately before another refinement in the chain is called its predecessor. The order 
of the refinements in a refinement chain is determined by their composition order. On 
the right side in Figure [T[ we depict the refinement and inheritance relationships of our 
email example. 

Fields are unique within the scope of a class and its inheritance hierarchy and re- 
finement chain. That is, a refinement or subclass is not allowed to add a field that has 
already been defined in a predecessor in the refinement chain or in a superclass. For 
example, a further refinement of Trans would not be allowed to add a field key, since 
key has been introduced by a refinement of feature SSL already. With methods, this is 
different. A refinement or subclass may add new methods (overloading is prohibited) 
and override existing methods. In order to distinguish the two cases, FFJ expects the 
programmer to declare whether a method overrides an existing method (using the mod- 
ifier overrides). For example, the refinement of Trans in feature SSL overrides the 
method send introduced by feature Mail; for subclasses, this is similar. 

The distinction between method introduction and overriding allows the type system 
to check (1) whether an introduced method inadvertently replaces or occludes an ex- 
isting method with the same name and (2) whether, for every overriding method, there 
is a proper method to be overridden. Apart from the modifier overrides, a method in 
FFJ is similar to a method in FJ. That is, a method body is an expression (prefixed with 
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return) and not a sequence of statements. This is due to the functional nature of FFJ 
and FJ. Furthermore, overloading of methods (introducing methods with equal names 
and different argument types) is not allowed in FFJ (and FJ). 

As shown in Figure [T] refinement chains grow from left to right and inheritance 
hierarchies from top to bottom. When looking up a method body, FFJ traverses the 
combined inheritance and refinement hierarchy of an object and selects the right-most 
and bottom-most body of a method declaration or method refinement that is compati- 
ble. This kind of lookup is necessary since we model features directly in FFJ, instead 
of generating and evaluating FJ code |40|. First, the FFJ calculus looks for a method 
declaration in the refinement chain of the object's class, starting with the last refinement 
back to the class declaration itself. The first body of a matching method declaration is 
returned. If the method is not found in the class' refinement chain or in its own dec- 
laration, the methods in the superclass (and then the superclass' superclass, etc.) are 
searched, each again from the most specific refinement of the class declaration itself. 
The field lookup works similarly, except that the entire inheritance and refinement hier- 
archy is searched and the fields are accumulated in a list. In Figure |2j we illustrate the 
processes of method body and field lookup schematically. 



Object 



Class, ^ «- (Ref,„,,) ) ..- (Refi^^p,,) ) e ^Ref(„,p| ) 




Class„_i ^ Ref|„_, •«- ^ Ref(n-i ,k_i) <- ( Ref(„_i ^) 

- A 

Class„ ^ ^-( Ref|^ - -.H ^f(,,,_,, )<- ^Ref(„,^) ) 



Fig. 2. Order of method body and field lookup in FFJ. 



2.2 Syntax of FFJ 

Before we go into detail, let us explain some notational conventions. We abbreviate lists 
in the obvious ways: 

- C is shorthand for Ci, . . . , C„ 

- C f is shorthand for Ci fi, ... , C„ f„ 

- C f ; is shorthand for Ci fi ; . . . ; C„ f„; 

- t : C is shorthand for ti : Ci, . . . , t„ : C„ 

- C <: D is shorthand for Ci <: Di . . . Cn <■ Dn 

Note that, depending on the context, blanks, commas, or semicolons separate the el- 
ements of a list. The context will make clear which separator is meant. The symbol • 
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denotes the empty list and lists of field declarations, method declarations, and parameter 
names must not contain duplicates. We use the metavariables A-E for class names, f-h 
for field names, and m for method names. Feature names are denoted by Greek letters. 

In Figure [3] we depict the syntax of FFJ in extended Backus-Naur-Form. An FFJ 
program consists of a set of class and refinement declarations. A class declaration L 
declares a class with the name C that inherits from a superclass D and consists of a list 
C f; of fields and a list M of method declarations|^A refinement declaration R consists 
of a list C f ; of fields and a list M of method declarations. 



L ::= class declarations: 

class C extends D { Cl; M } 

R ::= refinement declarations: 

refines class C { C f; M } 

M ::= method declarations: 

[overrides] C m(C x) { return t; } 



t::= terms: 

X variable 

t.f field access 
t.m(t) method invocation 

new C(t) object creation 

(C) t cast 

V ::= values: 

new C(v) object creation 



Fig. 3. Syntax of FFJ in extended BNF. 



A method m expects a list C X of arguments and declares a body that returns only 
a single expression t of type C. Using the modifier overrides, a method declares that it 
intends to override another method with the same name and signature. Where we want 
to distinguish methods that override others and methods that do not override others, we 
call the former method introductions and the latter method refinements 

Finally, there are five forms of terms: the variable, field access, method invocation, 
object creation, and type cast, which are taken from FJ without change. The only values 
are object creations whose arguments are values as well. 



2.3 FFJ's Class Table 

Declarations of classes and refinements can be looked up via a class table CT. The com- 
piler fills the class table during the parser pass. In contrast to FJ, class and refinement 
declarations are identified not only by their names but, additionally, by the names of 
the enclosing features. For example, in order to retrieve the declaration of class Trans, 
introduced by feature Mail, in our example of Figure [T] we write Cr(MAiL. Trans); 
in order to retrieve the refinement of class Trans applied by feature SSL, we write 
Cr(SSL. Trans). We call $.C the qualified type of class C in feature $. In FFJ, class 
and refinement declarations are unique with respect to their qualified types. This prop- 
erty is ensured because of the following sanity conditions: a feature is not allowed 

^ The concept of a class constructor is unnecessary in FFJ and FJ [541. Its omittance simplifies 
the syntax, semantics, and type rules significantly without loss of generality. 
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- to introduce a class or refinement twice inside a single feature module and 

- to refine a class that the feature has just introduced. 

These are common sanity conditions in feature-oriented languages and tools II13I10I9I . 

As for FJ, we impose further sanity conditions on the class table and the inheritance 
relation: 

- CT{^.C) = class C. . . or refines class C. . . for every qualified type $.C G 
dom{CT); Feature Base plays the same role for features as Object plays for 
classes; it is a symbol denoting the empty feature at which lookups terminate. 

- Base.Object^ dom{CT); 

- for every class name C appearing anywhere in CT, we have <i>.C € dom{CT) for 
at least one feature $; and 

- the inheritance relation contains no cycles (incl. self -cycles). 

2.4 Refinement in FFJ 

Information about the refinement chain of a class can be retrieved using the refinement 
table RT. The compiler fills the refinement table during the parser pass. RT{C) yields 
a list of all features that either introduce or refine class C. The leftmost element of 
the result list is the feature that introduces the class C and, then, from left to right, the 
features are listed that refine class C in the order of their composition. In our example of 
Figure[T] RT{Trans) yields the Hst EmailClient, SSL. There is only a single sanity 
condition for the refinement table: 

- RT{C) ~ $ for every type C G dom{CT), with $ being the features that intro- 
duce and refine class C. 

In Figure |4j we show two functions for the navigation of the refinement chain that 
rely on RT. Function last returns, for a class name C, a qualified type ^„.C, in which 

refers to the feature that applies the final refinement to class C; if a class is not 
refined at all, '^^ refers to the feature that introduces class C. Function pred returns, 
for a qualified type <I>.C, another qualified type ^'„.C, in which ^„ refers to the feature 
that introduces or refines class C and that is the immediate predecessor of $ in the 
refinement chain; if there is no predecessor. Base. Object is returned. 

Navigating along the refinement chain 

RT(C) = ^ flr(c) = i>,$,n RT(C) = 

last(C,) = *„.C pred{^.C) = *„.C pred{^.C) = Base.Object 

Fig. 4. Refinement in FFJ. 
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2.5 Subtyping in FFJ 



In Figure |5] we show the subtype relation of FFJ. The subtype relation <: is defined 
by one rule each for reflexivity and transitivity and one rule for relating the type of a 
class to the type of its immediate superclass. It is not necessary to define subtyping over 
qualified types because only classes (not refinements) declare superclasses and there is 
only a single declaration per class. 



Subtyping 



C <: C 



C <: D 



D <: E 



C <: E 



C <: D 

cr($.C) = class C extends D { . . . } 
C <: D 



Fig. 5. Subtyping in FFJ. 



2.6 Auxiliary Definitions of FFJ 

In Figure |6] we show the auxiliary definitions of FFJ. Function ^eMs searches the re- 
finement chain from right to left and accumulates the fields into a list (using the comma 
as concatenation operator). If there is no further predecessor in the refinement chain, 
i.e., we have reached a class declaration, then the refinement chain of the superclass is 
searched (see Figure [2|i. If Base. Object is reached, the empty list is returned (denoted 
by). 

Function mbody looks up the most specific and most refined body of a method m. A 
body consists of the formal parameters X of a method and the actual term t representing 
the content. The search is like m fields. First, the refinement chain is searched from 
right to left and, then, the superclasses' refinement chains are searched, as illustrated in 
Figure|2] Note that [overrides] means that a given method declaration may (or may not) 
have the modifier This way, we are able to define uniform rules for method introduction 
and method refinement. Function mtype yields the signature B Bq of a declaration 
of method m. The lookup is like in mbody. 

Predicate introduce is used to check whether a class has been introduced by mul- 
tiple features and whether a field or method has been introduced multiple times in a 
class. Precisely, it states, in the case of classes, whether C has not been introduced by 
any feature other than $ and whether a method m or a field f has not been introduced 
by "I>.C or in any of its predecessors or superclasses. To evaluate it, we check, in the 
case of classes, whether CT(^'.C) yields a class declaration or not, for any feature ^' 
different from $, in the case of methods, whether mtype yields a signature or not and, 
in the case of fields, whether f is defined in the list of fields returned by fields. 

Predicate refine states whether, for a given refinement, a proper class has been 
declared previously in the refinement chain. The predicate override states whether a 
method m has been introduced before in some predecessor of $.C and whether the 
previous declaration of m has the given signature. 
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Field lookup fields{$.C) = C f 

/(eW.?(Basc. Object) = • 
Cr($.C) = class C extends D { Cl; M } Cr($.C) = refines class C { Cl; M } 



fields{<S>.C) = fields{last{D)), C f 
Method body lookup 



fieldsi^.C) ^fields(jjred{<S>.C)), Cf 



mbody{m,^.C) = (x,t) 



[overrides] B m(B x) { return t; } e M m is not defined in M 

Cr($.C) = class C extends D { Cl; M } Cr($.C) = class C extends D { Cl; M } 



mbody{m,^.C) = (x,t) 

[overrides] B m(B x) { return t; } G M 
Cr(*.C) = refines class C { Cl; M} 
mbody{m,^.C) = (x,t) 

Method type lookup 

Bo m(Bx) [ return t; } e M 

CT($.C) = class C extends D { Cl; M } 
mtype{m, $.C) = B^ Bo 

B(, m(Bx) I return t; } e M 
Cr($.C) = refines class C { Cl; M } 
mtype{m,<b.C) = B^-Bo 



mbody{m, #.C) = mbody{m, lastiU)) 

m is not defined in M 
Cr($.C) = refines class C { Cl; M } 
mbody{m,'b.C) = mbody{m,pred{^.C)) 



mtype{m, #.C) = C^-C 



m is not defined in M 
CT($.C) = class C extends D { Cl; M } 
mtype{rr\, $.C) = mtype{m, last{D)) 

m is not defined in M 
Cr($.C) = refines class C { Cl; M } 
mtype{m, 3>.C) = mtype{m,pred{<b.C)) 



Valid class introduction 



introduce {$.C) 



$ * : (^(^.C) = class C . . . A $ 7^ *) 



Valid field introduction 



Valid method introduction 



Valid class refinement 



introduce{^ .C) 



fi,elds{^.C) = E h f ^ h 
introduce{\, 3>.C) 



(m,$.C) ^ dom{mtype) 
intTvduce{m, $.C) 



introduce{\, 3>.C) 



introduce{m, $.C) 



refine{$.C) 



RT{C) = -^,^,n CrC^i.C) = Class C. 



refine{^.C) 



Valid method overriding 



override{rr\, $.C, C Co) 



mtype{m,^.C) = B-^Bq 



C = B 



Co = Bo 



override{m, <3>.C, C — >■ Co) 
9 



Fig. 6. Auxiliary definitions of FFJ. 



2.7 Evaluation of FFJ Programs 

Each FFJ program consists of a class table and a termj^The term is evaluated using the 
evaluation rules shown in Figure|7] The evaluation terminates when a value, i.e., a term 
of the form new C(v), is reached. Note that we use a direct semantics of class refine- 
ment BOl . That is, the field and method lookup mechanisms incorporate all refinements 
when a class is searched for fields and methods. An alternative, which is discussed in 
Section|5] would be a. flattening semantics, i.e., to merge a class in a preprocessing step 
with all of its refinements into a single declaration. 



fields(last{C)) = C f 
(new C(v)).fi — > Vi 

mbody{m,last{C)) = (x, to) 



(new C{v)).m(u) — > [x u,this i-> new C(v)]to 
C <: D 



(D)(newC(v)) - 


— > new C(v) 


to — 


> t;, 


to.f — 


> t;,.f 


to — 


> t;, 


to.m(t) — 


> t;,.m(t) 


U — 




Vo.m(v, ti,t) — 


> Vo.m(v, t;,t) 


U — 




new C(v, ti, t) — 


> newC(v, t-,t) 


to — 




(C)to.f — 


> (C)t;,.f 



(E-ProjNew) 
(E-InvkNew) 
(E-CastNew) 

(E-Field) 
(E-InvkRecv) 
(E-InvkArg) 
(E-NewArg) 

(E-Cast) 



Fig. 7. Evaluation of FFJ programs. 



Using the subtype relation <: and the auxihary functions^eWs and mbody, the eval- 
uation of FFJ is fairly simple. The first three rules are most interesting (the remaining 
rules are just congruence rules). Rule E-ProjNew describes the projection of a field 
from an instantiated class. A projected field U evaluates to a value that has been 
passed as argument to the instantiation. Function fields is used to look up the fields 
of the given class. It receives last{C) as argument since we want to search the entire 
refinement chain of class C from right to left (cf. Figure |2|. 

Rule E-Proj1nvk evaluates a method invocation by replacing the invocation with 
the method's body. The formal parameters of the method are substituted in the body for 

^ The refinement table is not relevant for evaluation. 
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the arguments of the invocation; the value on which the method is invoked is substituted 
for this. The function mbody is called with the last refinement of the class C in order to 
search the refinement chain from right to left and return the most specific method body 
(cf. Figure [2|l. 

Rule E-CastNew evaluates an upcast by simply removing the cast. Of course, the 
premise must be that the cast is really an upcast and not a downcast or an incorrect cast. 

2.8 Type Checking FFJ Programs 

The type relation of FFJ consists of the type rules for terms and the well-formedness 
rules for classes, refinements, and methods, shown in Figures|8]and[9] 



Term typing 



X : C e r 
r I- X : c 

r h to : Co fieldsjlastjCo)) ^ Cl 

r h to.f. : c, 



r h t : c 

(T-Var) 
(T-Field) 



r I- to : Co r I- t : c 



mtype{rT\, last{Co)) = D— >-C 



C <: D 



r h to.m(t) : C 



r I- t : C fields(last{C)) = D f C <: D 
r I- new C(t) : C 

r h to : D D <: C 
r h (C)to : C 

rhtpiP C<:D C/D 
r h (C)to : c 

FhtoiD C ^. D D ^: C stupid warning 

r h (C)to : c 



(T-Invk) 



(T-New) 
(T-UCast) 
(T-DCast) 
(T-SCast) 



Fig. 8. Term typing in FFJ. 



Term Typing Rules. A term typing judgment is a triple consisting of a typing context 
r, a term t, and a type C (see Figurejsjl. 

Rule T-Var checks whether a free variable is contained in the typing context. Rule 
T-FlELD checks whether a field access to.f is well-typed. Specifically, it checks whether 
f is declared in the type of to and whether the type f equals the type of the entire term. 
Rule T-Invk checks whether a method invocation to.m(t) is well-typed. To this end, 
it checks whether the arguments t of the invocation are subtypes of the types of the 
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Method typing | M OK -I <i>.C 

xTB,this : C h t(, : E,, E,, <: B„ 
Cr(<l).C) = class C extends D { Cl; M } inrnHluccim, lasi{D)) 
Bo m(Bx) { return to; } OK H *.C 

xTB,this : C I- to : Eo Eo <: Bo 
Cr($.C) = class C extends D { Cl; M } override {m, last{D),B^ Bo) 

overrides Bo m(B x) { return to; } OK H $.0 

X : B,this : C I- to : Eo Eo <: Bo 
Cr($.C) = refines class C { C f; M } introduce{m,pred{^.C)) 
Bo m(Bx) { return to; } OK H *.C 

X : B,this : C I- to : Eo Eo <: Bo 
Cr(#.C) = refines class C { Cl; M } overnWe(m,prerf($.C), B^-Bo) 

overrides Bo m(B x) { return to; } OK H $.C 



Class typing 



LOKH $ 



Vf € f : mfrorf«ce(f, /a.s?(D)) introduce {^.C) M OK H $.C 
class C extends D { Cl; M } OK ^ $ 



ROK^ $ 



Refinement typing 

Vf e f : tntroduce{i,pred{^.C)) refine{$.C) M OK H $.C 
refines class C { Cl; M } OK H $ 

Fig. 9. Well-formedness rules of FFJ. 
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formal parameters of m and whether the return type of m equals the type of the entire 
term. Rule T-New checks whether an object creation new C(t) is well-typed in that it 
checks whether the arguments f of the instantiation of C are subtypes of the types D of 
the fields of C and whether C equals the type of the entire term. The rules T-UCast, 
T-DCast, and T-SCast check whether casts are well-typed. In each rule, it is checked 
whether the type C the term to is cast to is a subtype, supertype, or unrelated type of the 
type of to and whether C equals the type of the entire term|j 

Well-Formedness Rules. In Figure|9] we show FFJ's well-formedness rules of classes, 
refinements, and methods. 

The typing judgments of classes and refinements are binary relations between a 
class or refinement declaration and a feature, written L OK H $ and R OK H $. The 
rule of classes checks whether all methods are well-formed in the context of the class' 
qualified type. Moreover, it checks whether none of the fields of the class declaration 
is introduced multiple times in the combined inheritance and refinement hierarchy and 
whether there is no feature other than $ that introduces a class C (using introduce). The 
well-formedness rule of refinements is analogous, except that the rule checks whether 
a corresponding class has been introduced before (using refine). 

The typing judgment of methods is a binary relation between a method declaration 
and the qualified type that declares the method, written M OK H (&.C. There are four 
different rules for methods (from top to bottom in Figure |9|l 

1. that do not override another method and that are declared by classes, 

2. that override another method and that are declared by classes, 

3. that do not override another method and that are declared by refinements, 

4. that override another method and that are declared by refinements. 

All four rules check whether the type Eo of the method body is a subtype of the declared 
return type Bq of the method declaration. For methods that are being introduced, it is 
checked whether no method with an identical name has been introduced in a superclass 
(Rule 1) or in a predecessor in the refinement chain (Rule 3). For methods that override 
other methods, it is checked whether a method with identical name and signature exists 
in the superclass (Rule 2) or in a predecessor in the refinement chain (Rule 4). 

Well-Typed FFJ Programs. Finally, an FFJ program, consisting of a term, a class 
table, and a refinement table, is well-typed if 

- the term is well-typed (checked using FFJ's term typing rules), 

- all classes and refinements stored in the class table are well-typed (checked using 
FFJ's well-formedness rules), and 

- the class and refinement tables are well-formed (ensured by the corresponding san- 
ity conditions). 

* Rule T-SCast is needed only for the small step semantics of FFJ (and FJ) in order to be 
able to formulate and prove the type preservation property. FFJ (and FJ) programs whose type 
derivation contains this rule (i.e., the premise stupid warning appears in the derivation) are 
not further considered (cf. L32J ). 
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Type Soundness of FFJ. The type system of FFJ is sound. We can prove this using the 
standard theorems of preservation and progress ll66ll : 

Theorem 2.1 {Preservation) If T h t : C and t — ^ t', then T h t': C for some 
C'<: C. 

Theorem 2.2 {Progress) Suppose t is a well-typed term. 

1. If t includes new Co(t).fi as a subterm, l\\e\\fields{last{Ct:,)) = C f for some C and 
f. 

2. If t includes new Co(t).m(LJ) as a subterm, then mbody{vr\, last{Co)) = (x, to) and 
|x| = |u| for some X and to. 

We provide the proofs of the two theorems in Appendix [A] 

3 Feature-Oriented Product Lines in FFJ pl 

In this section, our goal is to define a type system for feature-oriented product lines - 
a type system that checks whether all valid combinations of features yield well-typed 
programs. In this scenario, the features in question may be optional or mutually ex- 
clusive so that different combinations are possible that form different feature-oriented 
programs. Since there may be plenty of valid combinations, type checking all of them 
individually is usually not feasible. 

In order to provide a type system for feature-oriented product lines, we need infor- 
mation about which combinations of features are valid, i.e., which features are manda- 
tory, optional, or mutually exclusive, and we need to adapt the subtype and type rules 
of FFJ to check that there are no combinations/variants that lead to ill-typed terms. 
The type system guarantees that every program derived from a well-typed product line 
is a well-typed FFJ program. FFJ together with the type system for checking feature- 
oriented product lines is henceforth called FFJp^. 



3.1 An Overview of Feature-Oriented Product Lines 

A feature-oriented product line is made up of a set of feature modules and a fea- 
ture model. The feature modules contains the features' implementation and the feature 
model describes how the feature modules can be combined. In contrast to the feature- 
oriented programs of Section |2] typically, some features are optional and some are mu- 
tually exclusive (Also other relations such as disjunction, negation, and implication are 
possible [12 J; they are broken down to mandatory, optional, and mutually exclusive 
features, as we will explain.). Generally, in a derivation step, a user selects a valid sub- 
set of features from which, subsequently, a feature-oriented program is derived. In our 
case, derivation means assembling the corresponding feature modules for a given set of 
features. In Figure [TOl we illustrate the process of program derivation. 

Typically, a wide variety of programs can be derived from a product line 021I19L 
The challenge is to define a type system that guarantees, on the basis of the feature 
modules and the feature model, that all valid programs are well-typed. Once a program 
is derived from such a product line, we can be sure that it is well-typed and we can 



evaluate it using the standard evaluation rules of FFJ (see Section 2.7 1 



14 



feature-oriented product line 



feature modules 




feature model 



user's feature 
selection 



feature-oriented programs 
program program 



Fig. 10. The process of deriving programs from a product line. 



3.2 Managing Variability - Feature Models 

The aim of developing a product line is to manage the variability of a set of programs 
developed for a particular domain and to facilitate the reuse of feature implementations 
among the programs of the domain. A feature model captures the variability by (explic- 
itly or implicitly) defining an ordered set of all features of a product line and their legal 
feature combinations. A well-defined feature order is essential for field and method 



lookup (see Section 3.6 1. 

Different approaches to product line engineering use different representations of 
feature models to define legal feature combinations. The simplest approach is to enu- 
merate all legal feature combinations. In practice, commonly different flavors of tree 
structures are used, sometimes in combination with additional propositional constraints. 



to define legal combinations [21 12 |, as illustrated in Figure 10 



For our purpose, the actual representation of legal feature combinations is not rele- 
vant. In FFJpi, we use the feature model only to check whether feature and/or specific 
program elements are present in certain circumstances. A design decision of FFJp^ is 
to abstract from the concrete representation of the underlying feature model and rather 
to provide an interface to the feature model. This has to benefits: (1) we do not need 
to struggle with all the details of the formalization of feature models, which is well 
understood by researchers M12I22I64I23I and outside the scope of this paper, and (2) we 
are able to support different kinds of feature model representations, e.g., a tree struc- 
tures, grammars, or propositional formulas |,12 J. The interface to the feature model is 
simply a set of functions and predicates that we use to ask questions Uke "may (or may 
not) feature A be present together with feature B" or "is program element m present in 
every variant in which also feature A is present", i.e., "is program element m always 
reachable from feature A". 



3.3 Challenges of Type Checking 

Let us explain the challenges of type checking by extending our email example, as 



shown in Figure 11 Suppose our basic email client is refined to process incoming 



text messages (feature Text, Lines 1-8). Optionally, it is enabled to process HTML 
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messages, using either Mozilla's rendering engine (feature MoziLLA, Lines 9-12) 
or Safari's rendering engine (feature SAFARI, Lines 13-16). To this end, the features 
MOZILLA and SAFARI oveiTide the method render of class Display (Line 11 and 15) 
in order to invoke the respective rendering engines (field renderer. Lines 10 and 14) 
instead of the text printing function (Line 7). 



Feature TEXT 

1 refines class Trans { 

2 Unit receive(Msg msg) { 

3 return/* do something... */new Display().render(msg); 

4 ) 

5 } 

6 class Display { 

7 Unit render(Msg msg) { /* displa\ me.aage in text format */] 

8 } 



Feature MOZILLA 

9 refines class Display { 

10 MozillaRenderer renderer; 

11 overrides Unit render(Msg m) {/* render HTML message using the Mozilla eni>ine */} 

12 ) 



Feature SAFARI 

13 refines class Display { 

14 SafariRenderer renderer; 

15 overrides Unit render(Msg m) {/* render HTML message using the Safari engine */} 

16 } 



Fig. 11. A feature-oriented email client using Mozilla's and Safari's rendering engines. 



The first thing to observe is that the features MoziLLA and SAFARI rely on class 
Display and its method render introduced by feature Text. In order to guarantee that 
every derived program is well-formed, the type system checks whether Display and 
render are always reachable from the features MOZILLA and SAFARI, i.e., whether, 
in every program variant that contains MoziLLA and SAFARI, also feature Text is 
present. 

The second thing to observe is that the features MOZILLA and SAFARI both add 
a field renderer to Display (Lines 10 and 14), both of which have different types. In 
FFJ, a program with both feature modules would not be a well-typed program because 
the field renderer is introduced twice. However, Figure 1 1 is not intended to repre- 
sent a single feature-oriented program but a feature-oriented product line; the features 
Mozilla and Safari are mutually exclusive, as defined in the product line's feature 
model (stated earlier), and the type system has to take this fact into account. 

Let us summarize the key challenges of type checking product lines: 



- A global class table contains classes and refinements of all features of a product 
line, even if some features are optional or mutually exclusive so that they are present 
only in some derived programs. That is, a single class can be introduced by multiple 
features as long as the features are mutually exclusive. This is also the case for 
multiple introductions of methods and fields, which may even have different types. 
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- The presence of types, fields, and methods depends on the presence of the fea- 
tures that introduce them. A reference from the elements of a feature to a type, a 
field projection, or a method invocation is valid if the referenced element is always 
reachable from the referring feature, i.e., in every variant that contains the referring 
feature. 

- Like references, an extension of a program element, such as a class or method 
refinement, is valid only if the extended program element is always reachable from 
the feature that applies the refinement. 

- Refinements of classes and methods do not necessarily form linear refinement 
chains. There may be alternative refinements of a single class or method that ex- 
clude one another, as explained below. 



3.4 Collecting Information on Feature Modules 

For type checking, the FFJpl compiler collects various information on the feature mod- 
ules of the product line. Before the actual type checking is performed, the compiler fills 
three tables with information: the class table (CT), the introduction table (IT), and the 
refinement table (RT). 

The class table CT of FFJ^^ is like the one of FFJ and has to satisfy the same 
sanity conditions except that (1) there may be multiple declarations of a class (or field 
or method), as long as they are defined in are mutually exclusive features, and (2) there 
may be cycles in the inheritance hierarchy, but no cycles for each set of classes which 
are reachable from any given feature. 

The introduction table IT maps a type to a list $ of (mutually exclusive) features 
that introduce the type. The features returned by IT are listed in the order prescribed 



by the feature model. In our example of Figure 11a call of /r(Display) would return 
a list consisting only of the single feature Text. Likewise, the introduction table maps 
field and method names, in combination with their declaring classes, to features. For 
example, a call of /T(Display. Tenderer) would return the list Mozilla, Safari. The 
sanity conditions for the introduction table are straightforward: 

- IT{C) ~ $ for every type C G dom{CT), with $ being the features that introduce 
class C. 

- /r(C.f) = $ for every field f contained in some class C G dom{CT), with $ 
being the features that introduce field f . 

- /T(C.m) = $ for every method m contained in some class C G dom{CT), with 
<i> being the features that introduce method m. 

Much like in FFJ, in FFJ pi there is a refinement table RT. A call of RT{C) yields 
a list of all features that either introduce or refine class C, which is different from the 
introduction table that returns only the features that introduce class C. As with IT, the 
features returned by RT are listed in the order prescribed by the feature model. The 
sanity condition for FFJp^'s refinement table is identical to the one of FFJ, namely: 

- RT{C) = <& for every type C G dom{CT), with $ being the features that intro- 
duce and refine class C. 
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3.5 Feature Model Interface 



As said before, in FFJpl, we abstract from the concrete representation of the feature 
model and define instead an interface consisting of proper functions and predicates. 
There are two kinds of questions we want to ask about the feature model, which we 
explain next. 

First, we would like to know which features are never present together, which fea- 
tures are sometimes present together, and which features are always present together. To 
this end, we define two predicates, never and sometimes, and a function always. Pred- 
icate never (n, $) indicates that feature $ is never reachable in the context fl, i.e., there 
is no valid program variant in which the features fi and feature $ are present together. 
Predicate som,etimes(n,^) indicates that feature $ is sometimes present when the 
features fl are present, i.e., there are variants in which the features fl and feature $ are 
present together and there are variants in which they are not present together. Function 
always(il, $) is used to evaluate whether feature $ is always present in the context J7 
(either alone or within a group of alternative features). There are three cases: if feature <1> 
is always present in the context, always returns the feature again (always{^l, $) = <!>); 
if feature $ is not always present, but would be together with a certain group of mutu- 
ally exclusive features (i.e., one of the group is always present), always returns all 
features of this group {always{n, $) = $, \1/). If a feature is not present at all, neither 
alone nor together with other mutually exclusive features, always returns the empty 
list {always{^l, $) = •). The above predicates and function provide all information we 
need to know about the features' relationships. They are used especially for field and 
method lookup. 

Second, we would like to know whether a specific program element is always 
present when a given set of features is present. This is necessary to ensure that ref- 
erences to program elements are always valid (i.e., not dangling). We need two sources 
of information for that. First, we need to know all features that introduce the program 
element in question (determined using the introduction table) and, second, we need to 
know which combinations of features are legal (determined using the feature model). 
For the field Tenderer of our example, the introduction table would yield the features 
MoziLLA and Safari and, from the feature model, it follows that Mozilla and Sa- 
fari are mutually exclusive, i.e., net;er(MoziLLA, Safari). But it can happen that 
none of the two features is present, which can invalidate a reference to the field. The 
type system needs to know about this situation. 

To this end, we introduce a predicate validref that expresses that a program element 
is always reachable from a set of features. For example, validref {ft, C) holds if type 
C is always reachable from the context f2, validref {Q, C.f) holds if field f of class C 
is always reachable from the context fl, and validref {fl, Cm) holds if method m of 
class C is always reachable from the context f2. Applying validref to a list of program 
elements means that the conjunction of the predicates for every Ust element is taken. 
Finally, when we write validref {fl, C) H ^, we mean that program element C is always 
reachable from a context in a subset ^ of features of the product line. 

In our prototype, we have implemented the above functions and predicates using a 
SAT solver that reasons about propositional formulas representing constraints on legal 
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feature combinations (see Section [4]i, as proposed by Batory |12 | and Czarnecki and 
Pietroszek ll22ll . 



3.6 Refinement in FFJpx 



In Figure 12 we show the functions last and pred for the navigation along the refine- 
ment chain. The two functions are identical to the ones of FFJ (cf. Figure |4]l. However, 
in FFJpL, there may be alternative declarations of a class and, in the refinement chain, 
refinement declarations may even precede class declarations, as long as the declaring 
features are mutually exclusive. Let us illustrate refinement in FFJp^ by means of the 



example shown in Figure 13 Class C is introduced in the features $i and $3. Feature 
$2 refines class C introduced by feature $1 and feature <i>4 refines class C introduced by 
feature $3. Feature $1 and $2 are never present when feature $3 or <1>4 are present and 
vice versa. A call of RT{C) would return the list $1, . . . , $4, a call of last{C) would 
return the qualified type <I>4.C, and a call of pred{^4.C) would return the qualified type 
$3.C and so on. 



Navigating along the refinement chain 



last{C) = *„.C pred{^.C) = *„.C pred{^.C) = Base.Object 

Fig. 12. Refinement in FFJp^. 




<J>I <I>2 <J>, <I>4 



mutually exclusive 
Fig. 13. Multiple alternative refinements. 



3.7 Subtyping in FFJ pl 

The subtype relation is more complicated in FFJp^ than in FFJ. The reason is that 
a class may have multiple declarations in different features, each declaring possibly 
different superclasses, as illustrated in Figure[T4] That is, when checking whether a class 
is a subtype of another class, we need to check whether the subtype relation holds in 
all alternative inheritance paths that may be reached from a given context. For example, 
FooBar is a subtype of BarFoo because BarFoo is a superclass of FooBar in every 
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program variant (since always{^i,^2) = *i'2,'i'3); but FooBar is not a subtype of 
Foo and Bar because, in both cases, a program variant exists in which FooBar is not a 
(indirect) subclass of the class in question. 




BarFoo 

D d; 




BarFoo 

D d; 



FooBar 



>Bar J 



<^ and <Ii, are 
mutually exclusive and 
one of them is always 
present together with 



Fig. 14. Multiple inheritance chains in the presence of alternative features. 



In Figure 15 we show the subtype relation of FFIp^. The subtype relation C <: 
E H 17 is read as follows: in the context il, type C is a subtype of type E, i.e., type C is 
a subtype of type E in every variant in which also the features ft are present. The first 
rule in Figure [15] covers reflexivity and terminates the recursion over the inheritance 
hierarchy. The second rule states that class C is a subtype of class E if at least one 
declaration of C is always present (tested with validref) and if every of C's declarations 
that may be present together with ft (tested with sometimes) declares some type D as 
its supertype and D is a subtype of E in the context ft. That is, E must be a direct or 
indirect supertype of D in all variants in which the features fl are present. Additionally, 
supertype D must be always reachable from the context (fl, 'i'). When traversing the 
inheritance hierarchy, in each step, the context is extended by the feature that introduces 
the current class in question, e.g., $7 is extended with 'J. 

Interestingly, the second rule subsumes the two FFJ rules for transitivity and direct 
superclass declaration because some declarations of C may declare E directly as its 
superclass and some declarations may declare another superclass D that is, in turn, a 
subtype of E, and the rule must be applicable to both cases simultaneously. 



Subtyping C <: E H f2 

c <: c H n 

validref (Jl, C) 

WT r^/r^^ . T^ / cr(*.C) = class C extends D {... } 

C <: EHH 
Fig. 15. Subtyping in FFJpi. 
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Applied to our example of Figure 14 we have FooBar <: FooBar H $1 because 
of the reflexivity rule. We also have FooBar <: BarFoo H $1 because FooBar is 
reachable from feature $1 and every feature that introduces FooBar, namely $1, con- 
tains a corresponding class declaration that declares BarFoo as FooBar's superclass, 
and BarFoo is always reachable from $1. However, we have FooBar Foo H $1 
and FooBar ^i: Bar H $1 because FooBar's immediate superclass BarFoo is not 
always a subtype of Foo respectively of Bar. 



3.8 Auxiliary Definitions of FFJp£ 

Extending FFJ toward FFJp^ makes it necessary to add and modify some auxiliary 
functions. The most complex changes concern the field and method lookup mecha- 
nisms. 



Field Lookup. The auxiliary function jields collects the fields of a class including the 
fields of its superclasses and refinements. Since alternative class or refinement decla- 
rations may introduce alternative fields (or the same field with identical or alternative 
types), jields may return different fields for different feature selections. Since we want 
to type-check all valid variants, field returns multiple field lists (i.e., a list of lists) that 
cover all possible feature selections. Each inner list contains field declarations collected 
in an alternative path of the combined inheritance and refinement hierarchy. 

For legibility, we separate the inner lists using the delimiter 'o'. For example, look- 
ing up the fields of class FooBar in the context of feature $1 (Figure 14 1 yields the 
list A a, D d, E e o B b, D d, E e because the features $2 and $3 are mutually ex- 
clusive and one of them is present in each variant in which also $1 is present. For 
readability, we use the metavariables T and Q when referring to inner field lists. We 
abbreviate a list of lists of fields J^i o . . . o J>j by T . Analogously, T is shorthand for 

O . . . O J"„i O . . . O J"i 

Function fields receives a qualified type <1>.C and a context of selected features J7. 
If we want all possible field lists, the context is empty. If we want only field lists for 
a subset of feature selections, e.g., only the fields that can be referenced from a term 
in a specific feature module, we can use the context to specify one or more features of 
which we know that they must be selected. 

The basic idea of FFJ p^'s field lookup is to traverse the combined inheritance and 
refinement hierarchy much like in FFJ. There are four situations that are handled differ- 
ently: 



1. The field lookup returns the empty list when it reaches Base. Object. 

2. The field lookup ignores all fields that are introduced by features that are never 
present in a given context. 

3. The field lookup collects all fields that are introduced by features that are always 
present in a given context. References to these fields are always valid. 

4. The field lookup collects all fields that are introduced by features that may be 
present in a given context but that are not always present. In this case, a special 
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marker @ is added to the fields in question because we cannot guarantee that a ref- 
erence to this field is safe in the given contextj^It is up to the type system to decide, 
based on the marker, whether this situation may provoke an error (e.g., the type sys- 
tem ignores the marker when looking for duplicate fields but reports an error when 
type checking object creations). 
5. A special situation occurs when the field lookup identifies a group of alternative 
features. In such a group each feature is optional and excludes every other feature 
of the group and at least one feature of the group is always present in a given 
context. Once the field lookup identifies a group of alternative features, we split the 
result list, each list containing the fields of a feature of the group and the fields of 
the original list. 



Field lookup fi,elds{Q., <1>.C) = C f 

fields{U, $. Object) = • (FL-1) 
never{i^, "!>) 



fields{Q,$.C) = fields{Q,pred{^.C)) 

sometimes{^l, al'ways{^l,$) — $ 

CT($.C) = class C extends D { Cl; M } 

fields{Ti,$.C) = appendifieldsiU, last{D)),Cl) 

sometimes{Q.,<^) always{Q.,^) — <& 
Cr(cE'.C) = refines class C { Cl; M } 

fields {Q,^.C) = append {fields {Q,, pred{^.C)), C 

sometimes[Q., $) always{Q,, $) = • 
Cr($.C) = class C extends D { Cl; M } 

fields{Ti,$.C) = append{fields{Ii, last{D)),C~m) 

someUmes{^l, <E>) always{n, $) = • 
Cr($.C) = refines class C { Cl; M } 
fields {Tl,$.C) = append{fields{Ti, pred{<l>.C)),C~m) 

sometimes{Q.,^) always{Q,,<^) — 4' 
fields(n,^.C) = fields {{U, -9 i),<l>.C) o . . .ofields{{U, *„),<1>.C) 

Fig. 16. Field lookup in FFJ p]^. 



(FL-2) 



(FL-3.1) 



(FL-3.2) 



(FL-4.1) 



(FL-4.2) 



(FL-5) 



In order to distinguish the different cases, we use the predicates and functions de- 
fined in Section [33] (especially never, sometimes, and always). The definition of func- 

^ Note that the marker @ is generated during type checking, so we do not include it in the syntax 
of FFJ. 
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tion fields, shown in Figure 16 follows the intuition described above: Once Base. Object 
is reached, the recursion terminates (FL-1). When a feature is never reachable in the 
given context, fields ignores this feature and resumes with the previous one (FL-2). 
When a feature is mandatory (i.e., always present in a given context), the fields in ques- 
tion are added to each alternative result list, which were created in Rule FL-5 (FL-3.1 
and FL-3.2)0 When a feature is optional, the fields in question, annotated with the 
marker @, are added to each alternative result list (FL-4.1 and FL-4.2). When a feature 
is part of an alternative group of features, we cannot immediately decide how to pro- 
ceed. We split the result list in multiple lists (by means of multiple recursive invocations 
of fields), in which we add one of the alternative features to each context passed to an 
invocation of fields (FL-5). 



Method type lookup 



mii/pe(f2, m, <J>.C) = B-^Bo 



mtype{Q., m, Base. Object) = • (ML-1) 



Bo m(B x) { . . . } G M somettmes{Q., $) 
Cr(-l'.C) = Class C extends D { Cl; M } 



mtypeiyi, m,<^.C) — mtype{Q,m, pred{^.C)), mtype{fl,rr\, last{D)),B^Bo 

Bo m(B x) { . . . I G M sometimes(n, $) 
Cr($.C) = refines class C { Cl; M } 

mtype{^l,m,^.C) = mtype{^l,m, pred{^.C)),B^Bo 

(m is not defined in M V never{Q,^)) 
Cr($.C) = Class C extends D { Cl; M } 

mtype{fl, m, "I>.C) = mtype[Q,, m, pred(<l?.C)), mtype{fl, m, last{D)) 

(m is not defined in M V net)er(f2, $)) 
Cr($.C) = refines class C { Cl; M } 

mtj/pe(f2, m, <3?.C) — mtype{Q,m, pred{^.C)) 



(ML-2) 



(ML-3) 



(ML-4) 



(ML-5) 



Fig, 17. Method Lookup in FFJ pl. 



Method Type Lookup. Like in field lookup, in method lookup, we have to take al- 
ternative definitions of methods into account. But the lookup mechanism is simpler 
than in fields because the order of signatures found in the combined inheritance and 
refinement hierarchy is irrelevant for type checking. Hence, function mtype yields a 
simple list B— >Bo of signatures for a given method name m. For example, calling 



mij/pe($i, m, $1.0) in the context of Figure 14 yields the list D->A, B^B 



* Function append adds to each inner list of a list of field lists a given field. Its implementation 
is straightforward and omitted for brevity. 
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In Figure 17 we show the definition of function mtype. For Base. Object, the empty 
list is returned (ML-1). If a class that is sometimes reachable introduces a method in 
question (ML-2), its signature is added to the result list and all possible predecessors 
in the refinement chain (using pred) and all possible subclasses are searched (using 
last). Likewise, if a refinement that is sometimes reachable introduces a method with 
the name searched (ML-3), its signature is added to the result list and all possible prede- 
cessors in the refinement chain are searched (using pred). If a class or refinement does 
not declare a corresponding method (ML-4 and ML-5) or the a class is never reachable, 
the search proceeds with the possible superclasses or predecessors. 

The current definition of function mtype returns possibly many duplicate signatures. 
A straightforward optimization would be to remove duplicates before using the result 
list, which we omitted for simplicity. 



Valid class introduction 



introduce{Q,, $.C) 



a * • r '^^(*-^) = ^'^ss ^ extends D { C f; M } 

' \^ »]> 7^ $ someUmesip., >]>) 



introduceiyi, $.0) 



Valid field introduction 



introduce{n, f, "1>.C) 



VE h & fields {n,^.C) : f ^ h 
introduce{Q, f, <E>.C) 

Valid method introduction 



introduce{il, m, "I>.C) 



mtype{Q, m, <i?.C) — • 
introduceiyi, m, <J>.C) 



Valid class refinement 



refine{Cl, $.C) 



RT{C) = n validrefin, C) H * 



refine{Q, $.C) 



Valid method overriding 



•irfe(n, m,$.C,C->Co) 



RT{C) = *,<!>, n vahdrefin, Cm) H $ 
VB^Bo G mtype{n, m,$.C) : C = B A Co = Bo 
override{fl, m, ^.C, C— >-Co) 

Fig. 18. Valid introduction, refinement, and overriding in FFJp^. 
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Valid Introduction, Refinement, and Overriding. In Figure 18 we show predicates 
for checking the validity of introduction, refinement, and overriding in FFJ pl. Predicate 
introduce indicates whether a class with the qualified type $.C has not been introduced 
by any other feature ^' that may be present in the context fl. Likewise, introduce holds 
if a method m or a field f has not been introduced by a qualified type $.0 (including 
possible predecessors and superclasses) that may be present in the given context il. 
To this end, it checks either whether mtype yields the empty list or whether f is not 
contained in every inner list returned by fields. 

For a given refinement, predicate refine indicates whether a proper class, which is 
always reachable in the given context, has been declared previously in the refinement 
chain. We write validref{^,C) -\ 'i' in order to state that a declaration of class C 
has been introduced in the set ^ of features, which is only a subset of the features of 
the product line, namely the features that precede the feature that introduces class C. 
Predicate override indicates whether a declaration of method m has been introduced 
(and is always reachable) in some feature introduced by before the feature that refines 
m and whether every possible declaration of m in any predecessor of a <E>.C has the 
same signature. 



3.9 Type Relation of FFJpi 

The type relation of FFJ pl consists of type rules for terms and well-formedness rules 
for classes, refinements, and methods, shown in Figure[T9]and Figure pO] 



Term Typing Rules. A term typing judgment in FFJp^ is a quadruple, consisting of 
a typing context F, a term t, a list of types C, and a feature $ that contains the term 
(see Figure [T9|. A term can have multiple types in a product line because there may 
be multiple declarations of classes, fields, and methods. The list C contains all possible 
types a term can have. 

Rule T-VARpi is standard and does not refer to the feature model. It yields a list 
consisting only of the type of the variable in question. 

Rule T-FlELDpi checks whether a field access to.f is well-typed in every possi- 
ble variant in which also $ is present. Based on the possible types E of the term to 
the field f is accessed from, the rule checks whether f is always reachable from $ 
(using validref). Note that this is a key mechanism of FFJp^'s type system. It en- 
sures that a field, being accessed, is definitely present in every valid program variant 
in which the field access occurs - without generating all these variants. Furthermore, 

all possible fields of all possible types E are assembled in a nested list T,C in 
which C f denotes a declaration of the field f; the call of fields{^, last{E)) is shorthand 
for fields{^, last{Ei)) . . . fields{^, Zas<(E„)), in which the individual result lists are 
concatenated. Finally, the list of all possible types Cn, . . . , C„i, . . . , Ci„i, . . . , Cnm of 
field f becomes the list of types of the overall field access. Note that the result list may 
contain duplicates, which could be eliminated for optimization purposes. 

Rule T-lNVKpL checks whether a method invocation to.m(t) is well-typed in every 
possible variant in which also $ is present. Based on the possible types E of the term 
to the method m is invoked on, the rule checks whether m is always reachable from $ 
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Term typing 

X : C e r 



r h X : C H $ 
VE G E : validref{t>,E.\) 



V h t:CH$ 

(T-VARpi) 



r h to : E H $ fields{<i>, last{E)) = J", C f, ^ 

r h to.f : Cll, . . . , Cnl, • • • , Clm, ■ • • , Cnm H $ 



VE € E : 7;a/idre/($, E.m) VC G C, VD G D G D : C <: D H $ 



ri-to:EH$ ^l-t:C^<^> mtype(<i>,m, last ( E)) = D^B 

= (T-lNVKpi) 

r h to.m(t) : Bii, . . . , B„i, . . . , Bi^, . . . , B„^ H $ 

validref{^,C) VDg G :F, VC G C : C <: D ^ $ 
r I- t : C H 3> fieldsi^, last{C)) =7 @ ^7 



r h new C(t) : C H * 

validr-ef , C) 

ri-to:EH$ VEGE:(E<:C^$VC<:E^$) 
r I- (C)to : C H $ 

validref{^,C) stupid warning 
ri-to:EH$ 3EeE:(C5^:EH$AE^:CH$) 
r h (C)to : C H * 

Fig. 19. Term typing in FFIp^. 



(T-NeWpl) 



(T-UDCASTpi) 



(T-SCASTpi) 
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Method typing 



M OK H #.C 



X : B,this : C hto : E H * VEeE:E<:BoH$ 

validref {<t , B) introduce(^, m, last{D)) 

Cr($.C) = class C extends D { Cl; M } 
Bo m(Bx) { return to; } OK H $.C 



X : B, this :CI-to:EH<l' VE€E:E<:B„H$ 
validref{^, B) override{$, m, last{D), B— >Bo) 
Cr($.C) = Class C extends D { Cl; M } 

overrides Bo m(B x) { return to; } OK H ^.C 

xTB,this:CI-to:EH$ VE e E : E <: Bo H <E> 
validref{$, B) introduce{^ , m, pred{^.C)) 
Cr($.C) = refines class C { Cf; M } 
Bo m(Bx) { return to; } OK H #.C 



X : B, this :CI-to:EH$ VEgE:E<:BoM$ 
validref{$, B) override{^, m, pred{^.C), B— >■ Bo) 
CT($.C) = refines class C { Cl; M } 
overrides Bo m(Bx) { return to; } OK H $.C 



Class typing 

vaMref{^, D) 
Vfef : introduce{^J,last(D)) 



LOKH $ 



vahdref{^, C) 
■introduce{^, ^.C) 



M OK H $.C 



class C extends D { C f ; M } OK ^ $ 

Refinement typing 

validref{^, C) 
Vf e f : introduce J, pred{^.C)) re^ne($, $.C) 



ROKH $ 
MOKH $.C 



refines class C { C f ; M } OK H $ 



Fig. 20. Well-fonnedness rules of FFIpi^. 
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(using validref). As with field access, this check is essential. It ensures that in generated 
programs only methods are invoked that are also present. Furthermore, all possible 

signatures of m of all possible types E are assembled in the nested list D— >■ B and it is 
checked that all possible lists C of argument types of the method invocation are subtypes 
of all possible lists D of parameter types of the method (this implies that the lengths of 
the two lists must be equal). A method invocation has multiple types assembled in a list 
that contains all result types of method m determined by mtype. As with field access, 
duplicates should be eliminated for optimization purposes. 

Rule T-NEWpi checks whether an object creation new C(t) is well-typed in every 
possible variant in which also $ is present. Specifically, it checks whether there is a 
declaration of class C always reachable from Furthermore, all possible field combi- 
nations of C are assembled in the nested list J^, and it is checked whether all possible 
combinations of argument types passed to the object creation are subtypes of the types 
of all possible field combinations (this implies that the number of arguments types must 
equal the number of field types). The fields of the result list must not be annotated with 
the marker @ since optional fields may not be present in every variant and references 
may become invalid (see field lookup)QAn object creation has only a single type C. 

Rules T-UDCASTpi and T-SCASTp^ check whether casts are well-typed in every 
possible variant in which also $ is present. This is done by checking whether the type 
C the term to is cast to is always reachable from $ and whether this type is a subtype, 
supertype, or unrelated type of all possible types E the term to can have. We have only 
a single rule T-UDCASTp^ for up- and downcasts because the list E of possible types 
may contain super- and subtypes of C simultaneously. If there is a type in the list which 
leads to a stupid case, we flag a stupid warning. A cast yields a list containing only a 
single type C. 



Well-Formedness Rules. In Figure 20 we show the well-formedness rules of classes, 
refinements, and methods. 

Like in FFJ, the typing judgment of classes and refinements is a binary relation be- 
tween a class or refinement declaration and a feature. The rule of classes checks whether 
all methods are well-formed in the context of the class' qualified type. Moreover, it 
checks whether the class declaration is unique in the scope of the enclosing feature <i>, 
i.e., whether no other feature, that may be present together with feature $, introduces 
a class with an identical name (using introduce). Furthermore, it checks whether the 
superclass and all field types are always reachable from $ (using validref). Finally, it 
checks whether none of the fields of the class declaration have been introduced before 
(using introduce). The well-formedness rule of refinements is analogous, except that 
the rule checks that there is at least one class declaration reachable that is refined and 
that has been introduced before the refinement (using refine). 

The typing judgment of methods is a binary relation between a method declaration 
and the qualified type that declares the method. Like in FFJ, there are four different 



rules for methods (from top to bottom in Figure 20 1 



1. that do not override another method and that are declared by classes. 



^ The treatment of @ is semiformal but simplifies the rule. 
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2. that override another method and that are declared by classes, 

3. that do not override another method and that are declared by refinements, 

4. that override another method and that are declared by refinements. 

All four rules check whether all possible types E of the method body are subtypes of 
the declared return type Bq of the method and whether the argument types B are always 
reachable from the enclosing feature $ (using validref). 

For methods that are introduced, it is checked, using introduce, whether no method 
with identical name has been introduced in any possible superclass (Rule 1) or in any 
possible predecessor in the refinement chain (Rule 3). For methods that override other 
methods, it is checked, using override, whether a method with identical name and 
signature exists in any possible superclass (Rule 2) or in any possible predecessor in the 
refinement chain (Rule 4). 

Well-Typed FFJpx Product Lines. An FFJpi product line, consisting of a term, a 
class table, an introduction table, and a refinement table, is well-typed if 

- the term is well-typed (checked using FFJp/,'s term typing rules), 

- all classes and refinements stored in the class table are well-formed (checked using 
FFJpi's well-formedness rules), and 

- the class, introduction, and refinement tables are well-formed (ensured by the cor- 
responding sanity conditions). 

3.10 Type Safety of FFJpx 

Type checking in FFJp^ is based on information contained in the class table, introduc- 
tion table, refinement table, and feature model. The first three are filled by the compiler 
that has parsed the code base of the product line. The feature model is supplied directly 
by the user (or tool). The compiler determines which class and refinement declarations 
belong to which features. The classes and refinements of the class table are checked us- 
ing their well-formedness rules which, in turn, use the well-formedness rules for meth- 
ods and the term typing rules for method bodies. Several rules use the introduction and 
refinement tables in order to map types, fields, and methods to features and the fea- 
ture model to navigate along refinement chains and to check the presence of program 
elements. 

What does type safety mean in the context of a product line? The product Une itself 
is never evaluated; rather, different programs are derived that are then evaluated. Hence, 
the property we are interested in is that all programs that can be derived from a well- 
typed product Une are in tum weU-typed. Furthermore, we would Uke to be sure that 
all FFJpL product Unes, from which only well-typed FFJ programs can be derived, are 
well-typed. We formulate the two properties as the two theorems Correctness of ¥FJpL 
and Completeness of FFJ pl. 
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Correctness 



Theorem 3 . 1 (Correctness of FFJ pl) Given a well-typed FFJ pi product line pi (in- 
cluding with a well-typed term t, well-formed class, introduction, and refinement tables 
CT, IT, and RT, and a feature model FM), every program that can be derived with a 



valid feature selection fs is a well-typed FFJ program (cf. Figure 10 1 



pi = (t, CT, IT, RT, FM) pi is well-typed fs is vaHd in FM 
derive {pi, fs) is well-typed 

Function derive collects the feature modules from a product line according to a 
user's selection fs, i.e., non-selected feature modules are removed from the derived 
program. After this derivation step, the class table contains only classes and refinements 
stemming from the selected feature modules. We define a valid feature selection to be 
a list of features whose combination does not contradict the constraints implied by the 
feature model. 

The proof idea is to show that the type derivation tree of an FFJp^ product line 
is a superimposition of multiple so-called type derivation slices. As usual, the type 
derivation proceeds from the root (i.e., an initial type rule that checks the term and all 
classes and refinements of the class table) to the leaves (type rules that do not have a 
premise) of the type derivation tree. Each time a term has multiple types, e.g., a method 
has different alternative return types, which is caused by multiple mutually exclusive 
method declarations, the type derivation splits into multiple branches. With branch we 
refer only to positions in which the type derivation tree is split into multiple subtrees 
in order to type check multiple mutually exclusive term definitions. Each subtree from 
the root of the type derivation tree along the branches toward a leaf is a type derivation 
slice. Each slice corresponds to the type derivation of a feature-oriented program. 

Let us illustrate the concept of a type derivation slice by a simplified example. Sup- 
pose the application of an arbitrary type rule to a term t somewhere in the type deriva- 
tion. Term t has multiple types C due to different alternative definitions of t's subterms. 
For simplicity, we assume here that t has only a single subterm tg, like in the case of a 
field access (t = to.f), in which the overall term t has multiple types depending on tp's 
and f 's types; the rule can be easily extended to multiple subterms by adding a predicate 
per subterm. The type rule ensures the well-typedness of all possible variants of t on 
the basis of the variants of t's subterm to. Furthermore, the type rule checks whether a 
predicate predicate (e.g., C <: D) holds for each variant of the subterm with its possible 
types E, written predicate{lo '■ E^). The possible types C of the overall term follow in 
some way from the possible types E of its subterm. Predicate validref is used to check 
whether all referenced elements and types are present in all valid variants, including 
different combinations of optional features. For the general case, this can be written as 
follows; 



predicate(\.Q '. Ei) predicate{\.o : E2) ... predicate(\.o '. E^ 
to : E always{. . .) 

r h t ; C H $ 



-(T-*pl) 



The different uses of predicate in the premise of an FFJp^ type rule correspond 
to the branches in the type derivation that denote alternative definitions of subterms. 
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Hence, the premise of the FFJ pl type rule is the conjunction of the different premises 
that cover the different alternative definitions of the subterms of a term. 

The proof strategy is as follows. Assuming that the FFJp^ type system ensures that 
each slice is a valid FFJ type derivation (see Lemma [BTT] in Appendix |B.l| l and that 
each valid feature selection corresponds to a single slice (since alternative features have 



been removed; see Lemma B.2 in Appendix |B.l| i, each feature-oriented program that 
corresponds to a valid feature selection is guaranteed to be well-typed. Note that mul- 
tiple valid feature selections may correspond to the same shce because of the presence 
of optional features. It follows that, for every valid feature selection, we derive a well- 
formed FFJ program - since its type derivation is valid - whose evaluation satisfies the 
properties of progress and preservation (see Appendix [A|. In Appendix [B| we describe 



the proof of Theorem 3. 1 in more detail 



Completeness 

Theorem 3.2 (Completeness of FFJ pl) Given an FFJpi product line pi (including 
a well-typed term t, well-formed class, introduction, and refinement tables CT, IT, 
and RT, and a feature model FM), and given that all valid feature selections fs yield 



well-typed FFJ programs, according to Theorem 3.1 pi is a well-typed product line 
according to the rules of FFJp^. 

pi = (t, CT, IT, RT, FM) V/s : {fs is vaHd in FM ^ denve{pl,fs) is well-typed) 

pi is well-typed 

The proof idea is to examine three basic cases and to generalize subsequently: {\) pi 
has only mandatory features; (2) pi has only mandatory features except a single optional 
feature; (3) pi has only mandatory features except two mutually exclusive features. 
All other cases can be formulated as combinations of these three basic cases. To this 
end, we divide the possible relations between features into three disjoint sets: (1) a 
feature is reachable from another feature in all variants, (2) a feature is reachable from 
another feature in some, but not in all, variants, (3) two features are mutually exclusive. 
From these three possible relations, we can prove the three basic cases in isolation and, 
subsequently, construct a general case that can be phrased as a combination of the three 
basic cases. The description of the general case and the reduction finish the proof of 
Theorem|3.2| In Appendix [B| we describe the proof of Theorem 1X2] in detail. 



4 Implementation & Discussion 

We have implemented FFJ and FFJp^ in Haskell, including the program evaluation and 
type checking of product fines. The FFJp^ compiler expects a set of feature modules 
and a feature model both of which, together, represent the product line. A feature mod- 
ule is represented by a directory. The files found inside a feature module's directory are 
assigned to / belong to the enclosing feature. The FFJ pi compiler stores this informa- 
tion for type checking. Each file may contain multiple classes and class refinements. 



In Figure 21 we show a snapshot of our test environment, which is based on Echpse 
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and a Haskell plugiijj We use Eclipse to interpret or compile our FFJ and FFJ pl type 
systems and interpreters. Specifically, the figure shows the directory structure of our 
email system. The file EmailClient. features contains the user's feature selection and 
the feature model of the product line. 
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Fig. 21. Snapshot of the test environment of the Haskell implementation. 



The feature model of a product line is represented by a propositional formula, fol- 
lowing the approach of Batory |12 | and Czamecki and Pietroszek f22l. Propositional 
formulas are an effective way of representing the relationships between features (e.g., of 
specifying which feature implies the presence and absence of other features and of ma- 
chine checking whether a feature selection is valid). For example, we have implemented 
predicate sometimes as follows: 

sometimes{FM,Ti, ^f) = satisfiable{FM Afli A . . . AD,n A^) 

The feature model is an propositional formula; feature are variables; and satisfiable is 
a satisfiability solver. Likewise, we have implemented predicate always on the basis of 
logical reasoning on propositional formulas: 

always{FM = -n{satisfiable{^{FM ^ ((fJi A . . . A ^ *)))) 

For a more detailed explanation of how propositional formulas relate to feature models 
and feature selections, we refer the interest to the work of Batory 1(121 . 

In Figure |22] we show the textual specification of the feature model of our email 
system, which can be passed directly to the FFJp^ compiler. 

* http : / / eclipsefp . sourcef orge . net/haskell/ 
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1 features: 

2 EmailClient IMAP POPS MIME SSL Text Mozilla Safari 

3 

4 model: 

5 EmailClient Implies (IMAP or POPS); 

6 IMAP Implies EmailClient; 

7 POPS Implies EmailClient; 

8 MIME implies EmailClient; 

9 SSL implies EmailClient; 

10 Text implies (IMAP or POPS); 

11 Mozilla implies (IMAP or POPS); 

12 Safari implies (IMAP or POPS); 

13 Mozilla implies (not Safari); 

14 Safari implies (not Mozilla); 



Fig. 22. Feature model of an email client product line. 



The first section (features:) of the file representing the feature model defines an 
ordered set of names of the features of the product line and the second section (model:) 
defines constraints on the features' presence in the derived programs. In our example, 
each email cUent supports either the protocols IMAP, POP3, or both. Furthermore, every 
feature requires the presence of the base feature EmailClient. Feature Text requires 
either the presence of IMAP or POP3 or both - the same for MoziLLA and SAFARI. 
Finally, feature MoziLLA requires the absence of feature SAFARI and vice versa. 

On the basis of the feature modules and the feature model, FFJp^'s type system 
checks the entire product line and identifies valid program variants that still contain 
type errors. A SAT solver is used to check whether elements are never, sometimes, or 
always reachable. If an error is found, the product line is rejected as ill-formed. If not, 
a feature-oriented program guaranteed to be well-formed can derived on the basis of a 
user's feature selection. This program can be evaluated using the standard evaluation 
rules of FFJ, which we have also implemented in Haskell. 

In contrast to previous work on type checking feature-oriented product lines M64I23L 
our type system provides detailed error messages. This is possible due to the fine- 
grained checks at the level of individual term typing and well-formedness rules. For 
example, if a field access succeeds only in some program variants, this fact can be 
reported to the user and the error message can point to the erroneous field access. Pre- 
viously proposed type systems compose all code of all features of a product line and 
extract a single propositional formula, which is checked for satisfiability. If the formula 
is not satisfiable (i.e., a type error has occurred), it is not possible to identify the location 
that has caused the error (at least not without further information). See Section|5] for a 
detailed discussion of related approaches. 

We made several tests and experiments with our Haskell implementation. However, 
real-world tests were not feasible because of two reasons. First, in previous work it has 
been already demonstrated that feature-oriented product lines require proper type sys- 
tems and that type checking entire real-world product lines is feasible and useful [64|. 
Second, like FJ, FFJ is a core language into which all Java programs can be compiled 
and which, by its relative simplicity, is suited for the formal definition and proof of 
language properties - in our case, a type system and its correctness and completeness. 
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But, a core language is never suited for the development of real-world programs. This 
is why our examples and test programs are of similar size and complexity as the FJ ex- 
amples of Pierce |54|. Type checking our test programs required acceptable amounts of 
time (in the order of magnitude of milliseconds per product line). We do not claim to be 
able to handle full-sized feature-oriented product lines by hand-coding them in FFJpi. 
Rather, this would require an expansion of the type system to full Java (including sup- 
port for features as provided by AHEAD IJ3J or FeatureHouse [9|) - an enticing goal, 
but one for the future (especially, as Java's informal language specification ll28l has 688 
pages). Our work lays a foundation for implementing type systems in that it provides 
evidence that core feature-oriented mechanisms are type sound and type systems of 
feature-oriented product lines can be implemented correctly and completely. 

Still, we would like to make some predictions on the scalability of our approach. The 
novelty of our type system is that it incorporates alternative features and, consequently, 
alternative definitions of classes, fields, and methods. This leads to a type derivation tree 
with possibly multiple branches denoting alternative term types. Hence, performing a 
type derivation of product line with many alternative features may consume a significant 
amount of computation time and memory. It seems that this overhead is the price for 
allowing alternative implementation of program parts. 

Nevertheless, our approach minimizes the overhead caused by alternative features 
compared to the naive approach. In the naive approach, all possible programs are de- 
rived and type checked subsequently. In our approach, we type check the entire code 
base of the product line and branch the type derivation only at terms that really have 
multiple, alternative types, and not at the level of entire program variants, as done in 
the naive approach. Our experience with feature-oriented product lines shows that, usu- 
ally, there are not many alternative features in a product line, but mostly optional fea- 
tures II42I3I64I37I591 1 1 19.5,6.57 .60] . For example, in the Berkeley DB product line (JE 
edition; 80 000 lines of code) there are 99 feature modules, but only two pairs of them 
alternative r9'371; in the Graph Product Line there are 26 feature modules, of which 
only three pairs are alternative 142191 . A further observation is that most alternative fea- 
tures that we encountered do not alter types. That is, there are multiple definitions of 
fields and methods but with equal types. For example, GPL and Berkeley DB contain 
alternative definitions of a few methods but only with identical signatures. Type check- 
ing these product lines with our approach, the type derivation would have almost no 
branches. In the naive approach, still many program variants exist due to optional fea- 
tures. Hence, our approach is preferable. For example, in a product line with n features 
and c * n variants (with c being a constant), in our approach, the type system would 
have to check n feature modules (with some few branches in the type derivation and 
solving few simple SAT problems; see below) and, in the naive approach, the type sys- 
tem would have to check, at least, 2*n feature modules but, commonly, 2*n*m with 
m < n. For product lines with a higher degree of variability, e.g., with n? or even 2" 
variants the benefit of our approach becomes even more significant. We believe that this 
benefit can make a difference in real world product line engineering. 

A further point is that almost all typing and well-formedness rules contain calls to 
the built-in SAT solver. This results in possibly many invocations of the SAT solver 
at type checking time. Determining the satisfiabihty of a propositional formula is in 
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general an A/^T' -complete problem. However, it has been shown that the structures of 
propositional formulas occurring in software product lines are simple enough to scale 
satisfiability solving to thousands of features BTl . Furthermore, in our experiments, we 
have observed that many calls to the SAT solver are redundant, which is easy to see 
when thinking about type checking feature-oriented product lines where the presence 
of single types or members is checked in many type rules. We have implemented a 
caching mechanism to decrease the number of calls to the SAT solver to a minimum. 

Finally, the implementation in Haskell helped us a lot with the evaluation of the 
correctness of our type rules. It can serve other researchers to reproduce and evaluate 
our work and to experiment with further (feature-oriented) language mechanisms. The 
implementations of FFJ and FFJ pl, along with test programs, can be downloaded from 
the WebE] 

5 Related Work 

We divide our discussions of related work into two parts: the implementation, formal 
models, and type systems (1) of feature-oriented programs and (2) of feature oriented 
product lines. 

5.1 Feature-Oriented Programs 

FFJ has been inspired by several feature-oriented languages and tools, most notably 
AHEAD/Jak [13|, FeatureC-H- [10|, FeatureHouse [9|, and Prehofer's feature-oriented 
Java extension ll55l . Their key aim is to separate the implementation of software arti- 
facts, e.g., classes and methods, from the definition of features. That is, classes and re- 
finements are not annotated or declared to belong to a feature. There is no statement in 
the program text that defines explicitly a connection between code and features. Instead, 
the mapping of software artifacts to features is established via so-called containment hi- 
erarchies, which are basically directories containing software artifacts. The advantage 
of this approach is that a feature's implementation can include, beside classes in the 
form of Java files, also other supporting documents, e.g., documentation in the form of 
HTML files, grammar specifications in the form of JavaCC files, or build scripts and 
deployment descriptors in the form of XML files 1 13 1. To this end, feature composition 
merges not only classes with their refinements but also other artifacts, such as HTML 
or XML files, with their respective refinements |2 9 1. 

Another class of programming languages that provide mechanisms for the definition 
and extension of classes and class hierarchies includes, e.g., ContextL 11291 . Scala 11521 . 
and Classbox/J [14|. The difference to feature-oriented languages is that they provide 
explicit language constructs for aggregating the classes that belong to a feature, e.g., 
family classes, classboxes, or layers. This implies that non-code software artifacts can- 
not be included in a feature ifTTl . However, FFJ still models a subset of these languages, 
in particular, class refinement. 

Similarly, related work on a formalization of the key concepts underlying feature- 
oriented programming has not disassociated the concept of a feature from the level of 

' http : //www .fosd.de/ffj 



35 



code. Especially, calculi for mixins 126116111341 . traits ll41 j . family polymorphism and 
virtual classes II33I25I30I18I . path-dependent types 15215 IL open classes ||20| . depen- 
dent classes Il27l . and nested inheritance [30l either support only the refinement of sin- 
gle classes or expect the classes that form a semantically coherent unit (i.e., that belong 
to a feature) to be located in a physical module that is defined in the host programming 
language. For example, a virtual class is by definition an inner class of the enclosing 
object, and a classbox is a package that aggregates a set of related classes. Thus, FFJ 
differs from previous approaches in that it relies on contextual information that has been 
collected by the compiler, e.g., the features' composition order or the mapping of code 
to features. 

A different line of research aims at the language-independent reasoning about fea- 
tures II13I44I9I39L The calculus gDeep is most closely related to FFJ since it provides a 
type system for feature-oriented languages that is language-independent [4J. The idea is 
that the recursive process of merging software artifacts, when composing hierarchically 
structured features, is very similar for different host languages, e.g., for Java, C#, and 
XML. The calculus describes formally how feature composition is performed and what 
type constraints have to be satisfied. In contrast, FFJ does not aspire to be language- 
independent, although the key concepts can certainly be used with different languages. 
The advantage of FFJ is that its type system can be used to check whether terms of 
the host language (Java or FJ) violate the principles of feature orientation, e.g., whether 
methods refer to classes that have been added by other features. Due to its language 
independence, gDeep does not have enough information to perform such checks. 

5.2 Feature-Oriented Product Lines 

Our work on type checking feature-oriented product lines was motivated by the work 
of Thaker et al. |64|. They suggested the development of a type system for feature- 
oriented product lines that does not check all individual programs but the individual 
feature implementations. They have implemented an (incomplete) type system and, in a 
number of case studies on real product lines, they found numerous hidden errors using 
their type rules. Nevertheless, the implementation of their type system is ad-hoc in the 
sense that it is described only informally, and they do not provide a correctness and 
completeness proof Our type system has been inspired by their work and we were able 
to provide a formalization and a proof of type safety. 

In a parallel line of work, Delaware et al. have developed a formal model of a 
feature-oriented language, called Lightweight Feature Java (LFJ), and a type system 
for feature-oriented product lines |23 1. Their work was also influenced by the practical 
work of Thaker et al. So, it is not surprising that it is closest to ours. However, there are 
numerous differences. First, their formal model of a feature-oriented language is based 
on Lightweight Java (LJ) ||62| and not on Featherweight Java (FJ). While LJ is more 
expressive, it is also more complex. We decided for the simpler variant FJ, omitting, 
e.g., constructors and mutable state. Second, Delaware et al. do not model feature- 
oriented mechanisms, such as class or method refinements, directly in the semantics 
and type rules of the language. Instead, they introduce a transformation step in which 
LFJ code is "compiled down" to LJ code, i.e., they flatten refinement chains to single 
classes. Proceeding likewise, we would have to generate first an FJ program from an 
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FFJ product line and type check the FJ program (that consists of some or all possible 
features of the product line) subsequently. We refrained from such a transformation 
step in order to model the semantics of feature-oriented mechanisms directly in terms 
of dedicated field and method lookup mechanisms as well as special well-formed rules 
for method and class refinements. 

Lagorio et al. have shown that a flattening semantics and a direct semantics are 
equivalent BOl . An advantage of a "direct" semantics is that it allows a type checking 
and error reporting at a finer grain. In LFJ, all feature modules are composed and a 
single propositional formula is generated and tested for satisfiability; if the formula 
is not satisfiable, it is difficult to identify precisely the point of failure. In FFJp^, the 
individual type rules consult the feature model and can point directly to the point of 
failure. 

A further advantage of our approach is that it leaves open when feature composi- 
tion is performed. Currently, feature composition is modeled in FFJ/FFJ as a static 
process done before compilation but, with our approach, it becomes possible to model 
dynamic feature composition at run time [58 53 1 by making the class and feature tables 
and the feature model dynamic, i.e., allowing them to change during a computation. 
With LFJ this is not possible. Hutchins has shown that feature composition can be per- 
formed by an interpreter and partial evaluation can be used to pre-evaluate the parts of 
a composition that are static [31 1. However, Delaware et al. have developed a machine- 
checked model of their type system formalized with the theorem prover Coq flSl. Our 
proof is hand- written, but we have a Haskell implementation of the FFJ and FFJpi 
calculi that we have tested thoroughly. 

Even previously to the work of Thaker et al., Czarnecki et al. presented an automatic 
verification procedure for ensuring that no ill-structured UML model template instances 
will be generated from a valid feature selection fl22l . That is, they type check product 
lines that consist not of Java programs but of UML models. They use OCL (object 
constraint language) constraints to express and implement a type system for model 
composition. In this sense, their aim is very similar to that of FFJp^, but limited to 
model artifacts - although they have proposed to generalize their work to programming 
languages. 

Kastner et al. have implemented a tool, called CIDE, that allows a developer to 
decompose a software system into features via annotations f3E\. In contrast to other 
feature-oriented languages and tools, the link between code and features is established 
via annotations. If a user selects a set of features, all code that is annotated with features 
(using background colors) that are not present in the selection is removed. Kastner et 
al. have developed a formal calculus and a set of type rules that ensure that only well- 
typed programs can be generated from a valid feature selection 1361 . For example, if 
a method declaration is removed, the remaining code must not contain calls to this 
method. CIDE's type rules are related to the type rules of FFJp/^ but, so far, mutually 
exclusive features are not supported in CIDE. In some sense, FFJ pl and CIDE represent 
two sides of the same coin: the former aims at the composition of feature modules, the 
latter at the annotation of feature-related code. 
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6 Conclusion 



A feature-oriented product line imposes severe challenges on type checking. The naive 
approach of checking all individual programs of a product line is not feasible because 
of the combinatorial explosion of program variants. Hence, the only practical option is 
to check the entire code base of a product line, including all features, and, based on the 
information of which feature combinations are valid, to ensure that it is not possible to 
derive a valid program variant that contains type errors. 

We have developed such a type system based on a formal model of a feature- 
oriented Java-like language, called Feature Featherweight Java (FFJ). A distinguishing 
property of our work is that we have modeled the semantics and type rules for core 
feature-oriented mechanisms directly, without compiling feature-oriented code down to 
a lower-level representation such as object-oriented Java code. The direct semantics al- 
lows us to reason about core feature-oriented mechanisms in terms of themselves and 
not of generated lower-level code. A further advantage is the fine-grained error report- 
ing and that the time of feature composition may vary between compile time and run 
time. 

We have demonstrated and proved that, based on a valid feature selection, our type 
system ensures that every program of a feature-oriented product line is well-formed and 
that our type system is complete. Our implementation of FFJ, including the type system 
for product lines, indicates the feasibility of our approach and can serve as a testbed for 
experimenting with further feature-oriented mechanisms. 
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A Type Soundness Proof of FF J 

Before giving the main proof, we state and proof some required lemmas. 

Lemma A.l If mtype{m, last{D)) = C^-Cq, then mtype{rr\, last{C)) = C-)-Co for 
allC <: D. 

Proof Straightforward induction on the derivation of C <: D. There are two cases: 
First, if method m is not defined in the declaration or in any refinement of class C, 
then mtype{m, last{C)) should be the same as mtype{m, last{E)) where Cr(<I>.C) = 
class C extends E { . . . } for some <i>. This follows from the definition of mtype that 
searches E's refinement chain from right to left if m is not declared in C's refinement 
chain. Second, if m is defined in the declaration or in any refinement of class C, then 
mtype{m, last{C)) should also be the same as mtype{m, last{E)) with CT'($.C) = 
class C extends E { . . . } for some This case is covered by the well-formedness 
rules for methods that use the predicate override to ensure that m is properly overrid- 
den, i.e., the signatures of the overridden and the overriding declaration of m are equal, 
and that m is not introduced twice, i.e., overloading is not allowed in FFJ. □ 
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Lemma A. 2 (Term substitution preserves typing) If r,X : B h t : D and r,S : A, 
where A <: B, then T h [xTTs] t : C for some C <: D. 



Proof By induction on the derivation of F, X : B h t : D. 
Case (T-Var) t = x x : D e r 

If X ^ X, then the result is trivial since [x i~> s] X = x|^On the other hand, if X = Xj 
and D — B^, then, since [x s] X = S^, letting C = A^ finishes the case. 



Case (T-Field) t = to.f. r,x : B h to : Dq fields {last{Do)) = C f D ^ 

By the induction hypothesis, there is some Cq such that F h [x i— >■ s] to : Co and 
Co <: Do- It is easy to check t\\?A fields{last{Cij)) — (fields {last (D q)) , D g) for some 
D g. Therefore, by T-FlELD, F h ([xTTs] to).fi : C^. The fact that the refinements of 
a class may add new fields does not cause problems. D g contains all fields that Cq, 
including all of its refinements, add to Do- 

C ase ( T-Invk) t ^ to. m(t) F, x : B h to : Dq mty/?e(m, Zast(Do)) = D 
r,x:Bl-t:D D <: E 

By the induction hypothesis, there are some Co and C such that: 



F h [x^Ts] to : Co Co <: Dq F h [xl=Ts] t : C C <: D. 



By Lemma A.l we have mtype{m, last{Co)) = E — >■ D. Moreover, C <: E by the 
transitivity of <: . Therefore, by T-lNVK, F h [xl^Ts] to.m([xl=rs] t) : D. The key is 
that subclasses and refinements may override methods but the well-formedness rules of 
methods ensure that the method's type is not altered, i.e., there is no overloading in FFJ. 



Case (T-New) t = new D(t) fie Ids (last (D)) = D ^ F,x:Bht:C C<:D 



By the induction hypothesis, F h [xT^Ts] t : E for some E with E <: C. We have E <: D 
by the transitivity of <: . Therefore, by rule T-New, F h new D([xhTs] t) : D. Al- 
though refinements of class D may add new fields, rule T-New ensures that the argu- 
ments of the object creation match the overall fields of D, including all refinements, in 
number and types. That is, the number of arguments (t) equals the number of fields (f) 
which function fields returns. 

Case (T-UCast) t = (D)to F,xTBhto:C C <: D 

By the induction hypothesis, there is some E such that F h [x i— > s] to : E and E <: C. 
We have E <: D by the transitivity of <:, which yields F h (D)( [x i->- s] to) : D by 
T-UCast. 



Case (T-DCast) t = (D)to F,x:Bhto:C D<:C Dt^C 



Note that [x i— >■ s] X is an abbreviation for [Xi i— >■ Si , . . . , X„ S„] X. It means that all occur- 
rences of the variables Xi , . . . , X„ in the term X are substituted with the corresponsing terms 

Si , . . . , Sn • 
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By the induction hypothesis, there is some E such that F h [x s] to : E and E <: C. 
If E <: D or D <: E, then T h (D)([x h> s] to) : D by T-UCast or T-DCast, respec- 
tively. If both D ^f: E and E ^f: D, then T h (D)([x i-^ s] to) : D (with a stupid warning) 
by T-SCast. 

Case (T-SCast) t = (D)to r,xTB h to : C D ^: C C ff: D 

By the induction hypothesis, there is some E such that F h [xl^Ts] to : E and E <: C. 
This means that E ff: D because, in FFJ, each class has just one superclass and, if both 
E <: C and E <: D, then either C <: D or D <: C, which contradicts the induction hy- 
pothesis. So F h (D)( [xTTs] to) : D (with a stupid warning), by T-SCast. □ 

Lemma A. 3 (Weakening) If F h t : C, then F, x : D h t : C 

Proof Straightforward induction. The proof for FFJ is similar to the proof for FJ. □ 

Lemma A. 4 If mtype{m, last{Co)) = D-> D, and mbody{m, last{Co)) = (x,t), then 
for some Dq and some C <: D we have Co <: Do and x : D, this : Do h t : C . 

Proof By induction on the derivation of mbody{vr\, last{Co)). The base case (in which 
m is defined in the most specific refinement of Co) is easy since m is defined in 
CT{last{CQ)) and the well-formedness of the class table implies that we must have 
derived X : D, this : Co 1^ t : C by the well-formedness rules of methods. The induction 
step is also straightforward: if m is not defined in CT{last{Co)), then mhody searches 
the refinement chain from right to left; if m has not been found, the superclass' refine- 
ment chain is searched. There are two subcases: first, m is defined in the declaration or 
in any refinement of Co; this case is similar to the base case. Second, m is defined in a 
superclass Do of Cq or in one of Dq's refinements; in this case, the well-formedness of 
the class table implies that we must have derived X : D,this : Dq h t : C by the well- 
formedness rules of methods, which finishes the case. □ 

Note that this lemma holds because method refinements do not change the types of 
the arguments and the result of a method, overloading is not allowed, and this points 
always to the class that is introduced or refined. 

Theorem A.l {Preservation) If F h t : C and t — )• t', then F h t': C' for some 
C'<: C. 

Proof By induction on a derivation of t — > t', with a case analysis on the final rule. 

Case (E-ProjNew) t = new Co(v).fi t' = Vj fields{last{Co)) = Dl 

From the shape of t, we see that the final rule in the derivation of F h t : C must be 
T-FiELD, with premise F h new Co(v) : Dq, for some Do, and that C = Dj. Similarly, 
the last rule in the derivation of F h new Co(v) : Dq must be T-New, with premises 
F h V : C and C <: D, and with Dq = Cq. In particular, F h Vj : Cj, which finishes the 

case, since C; <: D^. 

Case (E-InvkNew) t = (new Co(v)).m(u) t' = [x i-j> u,this i-j> new Co(v)]to 
mbody{m, last{Co)) = (x,to) 
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The final rules in the derivation of F h t : C must be T-lNVK and T-New, with premises 
r h newCo(v) : Cp, F h uTC, C <: D, and mtype{m, lastiCo)) = D ^ C. By 
we ha ve X : D,this : Do h t : B for some Dq and B, with Cn < : Dq and 

we have 



Lemma 



A.4 



A.2 



B <: C. By Lemma |A.3[ r,x : D,this : Dq h to : B. Then, by Lemma 
r [x h-> u, this 1-^ new Co(v)] to : E for some E <: B. By the transitivity of <: , we ob- 
tain E <: C. Letting C' = E completes the case. 

Case (E-CastNew) t = (D)(new Co(v)) Co <: D t' = new Co(v) 

The proof of L h (D)(new Co(v)) : C must end with T-UCast since ending with T- 
SCast or T-DCast would contradict the assumption of Cq <: D. The premises of 
T-UCast give us L h new Co(v) : Co and D = C, finishing the case. 

The cases for the congruence rules are easy. We show just the case E-Cast. 

Case (E-Cast) t = (D)to t' = (D)t^ to — > tf. 

There are three subcases according to the last typing rule used. 

Subcase (T-UCast) r h to : Co Co <: D D = C 

By the induction hypothesis, F h to : Co for some Cq <: Cq. By transitivity of <:, 
Co <: C. Therefore, by T-UCast, F h (C)to : C (with no additional stupid warning). 

Subcase (T-DCast) F h to : Co D <: Co D ^ C 

By the induction hypothesis, F h to : Cq for some Cq <: Cq. If Cq <: C or C <: Cq, 
then F h (C)to : C by T-UCast or T-DCast (without any additional stupid warning). 
On the other hand, if both Cq ■jzf: C or C ff: Cq, then F h (C)tQ : C with a stupid warning 
by T-SCast. 

Subcase (T-SCast) F h to : Co D ^: Co Co f^: D D = C 

By the induction hypothesis, F h tp : Cg for some Cq <: Cq. Then, also Cq <f.'. C and 
C ■jzf: Cq. Therefore F h (C)tQ : C with a stupid warning. If Cq <f.'. C, then C <f.'. Cq 
since C ff: Cq and, therefore, F h (C)to : C with stupid warning. If Cq <: C, then F h 
(C)to : C by T-UCast (with no additional stupid warning). This subcase is analogous 



to the case T-SCast of the proof of Lemma A.2 □ 

Theorem A.2 (Progress) Suppose t is a well-typed term. 

L If t includes new Co(t).fi as a subterm, then^e/c/s(/asi(Co)) = C f for some C and 
f. 

2. If t includes new Co(t).m(ij) as a subterm, then mbody{m, ksi(Co)) — (x, to) and 
|x| = for some X and to. 

Proof If t has new Co(f).fi as a subterm, then, by well-typedness of the subterm, it is 
easy to check that fields{last{Co)) is well-defined and U appears in it. The fact that 
refinements may add fields (that have not been defined already) does not invalidate this 
conclusion. Note that for every field of a class, including its superclasses and all its 
refinements, there must be a proper argument. Similarly, if t has new Co(t).m(ij) as a 
subterm, then it is also easy to show that mbody{m, /ast(Co)) ~ (x, to) and |x| = |u| 
from the fact that mtype{m, Zasi(Co)) = C ^ D where |x| — |C|. This conclusion 
holds for FFJ since a method refinement must have the same signature than the method 
refined and overloading is not allowed. □ 
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Theorem A. 3 {Type soundness of FFJ) If h t : C and t — >* t' with t' a normal 
form, then t' is either a value V with h V : D and D <: C, or a term containing 
(D)(new C(t)) in which C <: D. 



Proof Immediate from Theorem A.l and A. 2 Nothing changes in the proof of Theo- 
rem|A.3|for FFJ compared to FJ. □ 



B Type Soundness Proof of FFJpx 

In this section, we provide proof sketches of the theorems Correctness of FFJp^ and 
Completeness of FFJp^. A further formalization would be desirable, but we have stopped 
at this point. As is often the case with formal systems, there is a trade-off between for- 
mal precision and legibility. We decided that a semi-formal development of the proof 
strategies are the best fit for our purposes. 



B.l Correctness 

Theorem B . 1 {Correctness of FFJ pl) Given a well-typed FFJp^ product line pi (in- 
cluding with a well-typed term t, well-formed class, introduction, and refinement tables 
CT, IT, and RT, and a feature model FM), every program that can be derived with a 
valid feature selection fs is a well-typed FFJ program (cf. Figure [T0|. 

pi = (t, CT, IT, RT, FM) pi is well-typed Js is vaUd in FM 
derive{pl,fs) is well-typed 

The proof strategy is as follows: assuming that the FFJ type system ensures that 
each slice is a valid FFJ type derivation (Lemma [B.l|i and that each valid feature se- 



lection corresponds to a single slice (Lemma B.l i, it follows that the corresponding 
feature-oriented program is well-formed. Before we prove Theorem |B.1| we develop 
two required lemmas that cover the two assumptions of our proof strategy. 

Lemma B . 1 Given a well-formed FFJp^ product line, every slice of the product line's 
type derivation corresponds to a (set of) valid type derivation(s) in FFJ. 

Proof (Proof sketch) Given a well-formed FFJp^ product line, the corresponding type 
derivation consists of possibly multiple slices. 

The basic case is easy: there is only a simple derivation without branches due to 
mutually exclusive features (optional features may be present). In this case, each term 
has only a single type, which is the one that would also be determined by FFJ. Fur- 
thermore, FFJpi guarantees that referenced types, methods, and fields are present in all 
valid variants, using the predicate validref. 

Let us illustrate this with the rule T-FlELDp^; the other rules are analogous: 

VE e E : vaUdrefi^, E.f) 



rhto:EH$ fields{<i>,last{E))^T,C\,g 

pit f -r r r r — (T-FiELDpi) 



46 



In the basic case there are no branches in the type derivation and thus the term 
to has only a single type Ei. For the same reason, fields returns only a simple list of 
fields that contains the declaration of field f. Finally, T-FlELDp^ checks whether the 
declaration of f is present in all valid variants (using validref). Hence, in the basic 
case, an FFJpl derivation that ends at the rule T-FlELDp^ is equivalent to a set of 
corresponding FFJ derivations, which do not contain alternative and optional features 
and thus to has a single type, fields returns a simple list of fields that contains the 
declaration of f, and the declaration of f is present. The reason that an FFJp^ derivation 
without mutually exclusive features (i.e., a single slice) corresponds to multiple FFJ 
derivations is that the FFJ p^ derivation may contain optional features whose different 
combinations correspond to the different FFJ derivations. Using predicate validref, all 
type rules of FFJ pl ensure that all possible combinations of optional features are well- 
typed. 

In the case that there are multiple sUces in the FFJ p^ derivation, a term to may have 
multiple types E . The type rules of FFJ p i make sure that every possible shape of a given 
term is well-typed. Each possible type of the term leads to a branch in the derivation 
tree. The premise of T-FlELDp^ checks whether all possible shapes of a given term 
are well-typed by taking the conjunction of all branches of the derivation. Hence, if 
T-FlELDpi^ is successful, each individual branch holds, i.e., each slice corresponds to a 
well-typed FFJ program. Ensuring that, in the presence of optional features, all relevant 
subterms are well-typed (i.e., all referenced elements are present in all valid variants), a 
well-typed slice covers a set of well-typed FFJ derivations that correspond to different 
combinations of optional features, like in the basic case. 

For example, in a field projection to.f, the subterm to has multiple types E. For all 
these types, fields yields all possible combinations of fields declared by the variants 
of the types. It is checked whether, for each type of the subterm to, each combination 
of fields contains a proper declaration of field f. The different types of f become the 
possible types of the overall field projection term. Like in the basic case, it is checked 
whether every possible type of to is present in all valid variants (using validref), so that 
each slice corresponds a valid FFJ derivation, i.e., a whole set of derivations covering 
different combinations of optional features. □ 

Lemma B . 2 Given a well-formed FFJ p ^ product line, each valid feature selection cor- 
responds to a single slice in the corresponding type derivation. 

Proof (Proof sketch) By definition, a valid feature selection does not contain mutually 
exclusive features. Considering only a single valid feature selection, each term has only 
a single type. But the type derivation of the overall product line contains branches corre- 
sponding to alternative types of the terms. A successive removal of mutually exclusive 
features removes these branches until only a single branch remains. Consequently, a 
valid feature selection corresponds to a single slice. □ 

Proof (Proof sketch of Theorem \B.1\ ( Correctness of FFJpi)) The fact that the FFJp^ 
type system ensures that each slice is a valid FFJ type derivation (Lemma[B.l[) and that 



each vaUd feature selection corresponds to a single slice (Lemma B.2 1, implies that each 
feature-oriented program that corresponds to a valid feature selection is well-formed. 

□ 
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B.2 Completeness 

Theorem B.2 {Completeness of FFipi) Given an FFJp^ product line pi (including 
a well-typed term t, well-formed class, introduction, and refinement tables CT, IT, 
and RT, and a feature model FM), and given that all valid feature selections fs yield 



well-typed FFJ programs, according to Theorem B.l pi is a well-typed product line 
according to the rules of FFJp^. 

pi = (t, CT, IT, RT, FM) V/s : {fs is vaHd in FM =^ denve{pl,fs) is well-typed) 

pi is well-typed 



Proof (Proof sketch of Theorem B.l (Completeness of FFJpi)) There are three basic 
cases: (1) pi has only mandatory features; (2) pi has only mandatory features except a 
single optional feature; (3) pi has only mandatory features except two mutually exclu- 



sive features. Proving Theorem B.2 for the first basic case is trivial. Since only manda- 
tory features exist, only a single FFJ program can be derived from the product line. If 
the FFJ program is well-typed, the product line is well-typed, too, because all elements 
are always reachable and each term has only a single type. In fact, the type rules of 
FFJ PL and FFJ become equivalent in this case. 

In the second basic case, two FFJ programs can be derived from the product line, 
one including and one excluding the optional feature. The difference between the two 
programs is the content of the optional feature. The feature can add new classes, refine 
existing classes by new methods and fields, and refine existing methods by overriding. 
If the two programs are well-typed, then the overall product line is well-typed as well 
since the reachability checks succeed in every type rule of FFJp^. Otherwise, at least 
one of the two programs would not be well-typed since, in this case, the reachability 
checks are the only difference between FFJ p^'s and FFJ's type rules (as in the first case, 
each term has only a single type since there are no mutually exclusive features). The 
fact that the two FJ programs are well-typed implies that all elements are reachable in 
the type derivations of two FFJ programs. Thus, the reachability checks of the FFJp^ 
derivation succeed in every case, i.e., the product line in question is well-typed. 

In the third basic case, two FFJ programs can be derived from the product line, 
one including the first alternative and the other including the second alternative of the 
feature in question. The difference between the two programs is, on the one hand, the 
program elements one feature introduces that are not present in the other and, on the 
other hand, the alternative definitions of similar elements, like two alternative defini- 
tions of a single class. The first kind of difference is already covered by the second 
basic case. Alternative definitions of a program element (second kind of difference) 
that are well-typed in the context of their enclosing FFJ programs, are well-typed in 
FFJ Pi because they lead to two new branches in the derivation tree which are handled 
separately and the conjunction of their premises must hold. Since the corresponding 
FFJ type rule for the element succeeds in both FFJ programs, their conjunction in the 
FFJ Pi type rule always holds, i.e., the product line in question is well-typed. 

Finally, we it remains to show that all other cases, i.e., all other combinations of 
mandatory, optional, and alternative features, can be reduced to combinations of the 



three basic cases, which proves Theorem B.2 To this end, we divide the possible rela 



tions between features into three disjoint sets; (1) a feature is reachable from another 



48 



feature in all variants, (2) a feature is reachable from another feature in some, but not 
in all, variants, (3) two features are mutually exclusive. From these three possible rela- 
tions we construct a general case that can be reduced to a combination of the three basic 
cases. 

Assume a feature $ that is mandatory with respect to a set of features H, that is 
optional with respect to a set of features ft, and that is alternative to a set A of features. 
We use arrows to illustrate to which of the three basic cases a pairwise relation between 
$ and each element of a list is reduced: 




Such an arrow diagram can be created for every feature of a product line. The reason is 
that the three kinds of relations are orthogonal and there are no further relations relevant 
for type checking. Hence, the general case covers all possible relations between features 
and combinations of features. The description of the general case and the reduction 
finish the proof of Theorem B. 2 i.e., FFIp^'s type system is complete. □ 



49 



